devopsy.kinsta.cloud

Category: DevOps and Open Technologies

Editorial Calendar for February 2016

  • IaC Frameworks: Vendor-Specific or Multi-Cloud?

    IaC Frameworks: Vendor-Specific or Multi-Cloud?

    Over the past few years, I have been watching the shift to infrastructure as code (IaC) frameworks closely. With the shift from monolithic to microservices, and with the shift from mostly virtual machines (VMs) to cloud-native architecture, applications are much more complicated, making it much more important to automate infrastructure to respond with speed.

    In that sense, I refer to IaC as “The third cloud revolution.” Looking at the history of cloud transformation, the shift from physical servers to virtual machines (led by VMware about 20 years ago) would be the first cloud revolution. The move from virtualized data centers to the public cloud (led by AWS about 10 years ago) would be the second cloud revolution. With the shift to public clouds, people were suddenly able to click buttons to provision new resources, including “hardware.”

    In the last few years however, we see fewer clicks and more code. Engineers write and maintain that IaC, and something executes that code. Engineers influence the infrastructure much more than they used to – that is the third cloud revolution. We mainly see four IaC frameworks that drove this revolution – Terraform and Pulumi (both multi-cloud), CloudFormation and ARM (vendor specific).

    I recently talked with Joe Duffy, CEO, Pulumi, Mark Russinovich, CTO, Azure and Anton Babenko, AWS community hero and Hashicorp ambassador, the head of Terraform at Microsoft, the head of Terraform at IBM Cloud and one of the founders at Gruntwork. After our brainstorming session, it’s clear we all agree that IaC will have a huge effect on cloud operations. In this blog, I’ll share my point of view regarding multi-vendor IaC versus single-vendor IaC frameworks; discuss how they compare to the differences between iOS and Android and which direction I believe will win the day.

    The big cloud vendors seem to go “all-in” and create full ecosystem, iOS-style, and they have everything working nicely with the relevant services and tools. AWS just released AWS Proton, which works with CloudFormation. They say that Terraform is on their roadmap, but time will tell. Microsoft seems to offer more solutions that are ARM-based, like Bicep. When I talk with executives at those companies, they strongly believe in the great value of this vendor lock-in/closed approach. They truly believe that this will help their customers in the best way possible. Perhaps they are right.

    On the other hand, when I talk with the community, I hear different opinions. DevOps engineers at Azure customers do not debate whether to choose Terraform or ARM. DevOps engineers at AWS customers do not debate whether to choose Cloudformation or Terraform. While this was the case three years ago, it is not, anymore. Now, the real debate is whether to choose Terraform or Pulumi. Engineers prefer a language that is multi-vendor, open-source, no vendor lock-in and that is compatible with other open source solutions built on top, like Open Policy Agent and Terragrunt, to help Terraform users. This is the Android-style approach – open platform.

    Moreover, I hear new phrases from the community that make me think the future is going in this direction. Erik Osterman at Cloud Posse started using the acronym  TACOS – Terraform Automation and Collaboration Software (see the video here). It takes time, but, going forward, developers and the community will hold the key to the future of IaC, not executives and large vendors.

    You can, of course, challenge this by replying that, “iOS is a great OS.” This is obviously true, but I think there is one big difference here as to why the Android approach is winning the IaC market. The answer lies with the end user; the Apple ecosystem is a solution for the end user and consumer, and IaC is about larger-scale infrastructure decisions. Like the shift from monolith to microservices, developers prefer small and isolated parts, not one big system. With Terraform and Pulumi, developers get more freedom. Maybe the company will move from AWS to GCP or Azure or vice versa. Maybe IT will need an Auth0 provider, as well, and will want to manage it the same way. Maybe the use of Open Policy Agent to govern deployments becomes the status quo. Developers need freedom, whereas consumers just need a great product.

    But the question has still not been answered: Terraform or Pulumi? It is still too early to tell, and, frankly, there is more than enough room in the IaC space for both. Maybe more open-source and multi-vendor frameworks will emerge and one that’s yet unknown will rule the day. Terraform provides a great ecosystem of providers, support and maintainers. Pulumi has started to provide all of those, together with its imperative approach, which seems to be a bit more appealing to developers.

  • Scarf Gateway Tracks Open Source Software Usage

    Scarf Gateway Tracks Open Source Software Usage

    Scarf today exited stealth to launch a gateway that makes it simpler for individuals or organizations to track usage of open source software.

    Avi Press, founder of Scarf, said the Scarf Gateway is an online service through which providers of open source software can redirect downloads from a wide range of repositories and registries. That extra step then provides those entities with data and insights about the type of individuals and organizations using their software.

    Fresh off raising initial seed funding, Press said the Scarf Gateway will make it easier for developers of open source software to employ multiple repositories to distribute their code, because they won’t become overly dependent on metrics shared by the provider of a single repository.

    Most of those registries today only provide download counts for packages. Scarf Gateway will provide insights into, among other attributes, downloads by version, platform, location, company and cloud environment(s).

    The majority of organizations making open source software available don’t have a lot of visibility into how their offerings are being employed until organizations using the software sign up for commercial support. Armed with more insights into how their software is being used, many of those providers would be able to more proactively collect feedback, in addition to promoting their commercial services.

    Many open source project maintainers have a difficult time prioritizing what capabilities to add or fix, simply because they don’t know enough about how their software is being employed, Press said.

    The ability to more granularly track usage comes at a time when tensions over open source monetization and compensation are rising. In many cases, providers of open source software are changing the way they license their software to prevent cloud service providers from reaping most of the benefits of their work. Startups, typically funded by venture capitalists, make their software available as open source code in an effort to build a customer base on the strength of their support services. Cloud service providers have discovered they can take the code these vendors create to launch their own service. Those cloud service providers may contribute code to the project, but the startup vendor doesn’t typically enjoy any of the economic benefits.

    Many individual contributors don’t work for a company that sponsors their contributions, and also want to be paid for their efforts. A survey of 4,440 developers who actively participated in open source projects in 2020 finds more than half (54%) of respondents said they feel individuals should be paid for their contributions to open source projects. The survey, conducted by Digital Ocean, a cloud service provider, found only 14% of respondents are currently paid for their contributions.

    It’s too early to say what impact the ability to track usage of open source software may have. Many individuals using open source software may prefer their current level of anonymity. Others might participate more in a project if engaged. Like it or not, however, large swaths of the open source community want to know the degree to which their efforts are making an actual difference.

  • Survey: The State of Database DevOps

    Survey: The State of Database DevOps

    Enterprises are undergoing rapid changes. Throughout the past year, companies have been pressed to learn a diversified set of technologies and methods to remain agile in a changing economy. In this digital-first world, data plays a heightened role; in tandem, so does the delivery of data and the persistence of the database layer itself.

    Applying DevOps principles and automation throughout the software life cycle is critical to maintaining a high level of efficiency. As with application development, databases are not immune to the DevOps takeover. Database DevOps is a discipline that considers the processes used to automate database changes and deployments — a field growing in mindshare as databases diversify.

    Seventy percent of companies now use more than one database in their stack. Many organizations now use a blend of on-premises and cloud databases. Styles are diverging, too, as non-relational databases like NoSQL gain favor, and new open-source databases emerge to fit niche circumstances. All of this means database operators may require an increased emphasis on database DevOps to handle additional complexity.

    The 2021 State of Database DevOps report, conducted by Redgate, surveyed 3,200 database professionals on the general state of their DevOps adoption. The survey also inquired about database change automation and deployment and underlying database technologies. Now, five years in, the study continues to reveal shifts in practices across industries.

    Below, we’ll review the report’s main takeaways to see how companies implement database DevOps in practice.

    DevOps Adoption Increases Across Projects

    To meet pressing digital innovation needs, DevOps has surged in importance across all industries — 74% of organizations have adopted some form of DevOps, and 26% of respondents reported applying DevOps practices across all projects — a significant uptick from previous years. The report acknowledges a slight increase in DevOps adoption among larger company sizes.

    So, which DevOps practices are companies employing the most? Well, in terms of DevOps for application development, the majority of organizations (50% or above) have adopted version control, automated builds, monitoring, automated unit tests, static code analysis and semi-automated deployments in production. Only 41% of organizations surveyed have fully automated deployments to production. These methods can be viewed as a basic benchmark for modern DevOps.

    The study demonstrated that in most organizations, DevOps is a communal undertaking. More respondents reported adopting a community of practice, rather than relying on individual decision makers, to disseminate DevOps strategies and direct planning. According to the report, a community of practice is a group of people that “makes decisions, provides recommendations, or is consulted.”

    Lack of Skills Tops DevOps Obstacles

    The pressure is on engineers to produce to meet digital transformation demands. However, organizations experiencing a developer drought may not possess the talent to introduce DevOps practices. It’s no surprise that the common obstacle hindering DevOps adoption was a “lack of appropriate skills in the team.”

    Other cultural barriers to DevOps adoption include disruption of existing workflows and a lack of alignment between teams. Interestingly, a lack of executive support was cited as the lowest hurdle to DevOps adoption, indicating universal consensus on DevOps goals. If we consider what technical barriers prevent improved software delivery and operations, 41% noted insufficient automation in release processes and 39% expressed hindrances due to legacy code.

    Continuous Delivery For Databases Increases

    Database DevOps appears to be growing in production use too. For the purpose of this study, Database DevOps is defined as “automating the delivery of database changes.” According to the report, 51% of respondents are already automating some parts of their database deployment process.

    Though growing year after year, database DevOps is nowhere near ubiquitous. Compared to DevOps in application development, database DevOps has lower overall use. For example, only 36% are implementing automated builds. And, only 22% adopt continuous delivery (CD) for all databases. Nevertheless, this could quickly change, though, as 80% of respondents are working to implement CD for database changes or have already implemented it.

    Setting up a CD process for database changes could increase overall software delivery speed. The top two drivers for adopting database automation are increasing the speed of database changes and freeing up time for other work. The third top reason, minimizing application downtime, rose in rank this year — which makes sense, as the desire to create more reliable systems is an ever-present concern.

    However, to reap these rewards, organizations must overcome some significant challenges, like synchronizing application and database changes and maintaining high speeds for database automation, among other concerns.

    Organizations Adopt Hybridized Database Approaches

    Companies increasingly use a mix of different database technologies and styles. We also see an increase in cloud and hybrid database estates.

    In terms of database styles, relational databases still make up the majority of market share — 98% of respondents have at least one relational database. However, non-relational databases, like NoSQL, are gaining popularity. Forty-seven percent of database professionals have a NoSQL database in their enterprise. Interestingly, only 2% use non-relational databases exclusively, indicating it’s a niche use case.

    Enterprises are now using more databases than ever before. Seventy percent of database professionals reported having more than one database in their stack. This figure rose nearly 10% since last year. Database types are multiplying too — 45% have more than one type of database. In terms of database management systems, Microsoft SQL Server holds the most use, at an 82% usage rate. Others like MySQL, Oracle, PostgreSQL, and MongoDB trail behind.

    Enterprises are also increasing their use of cloud and hybrid database deployment models. Eighty percent of respondents host a cloud database, and 65% report a mix of cloud and on-premises estate.

    One possible explanation for the diversified database effect is an increase in public cloud provider usage, combined with the rise of multicloud strategies. Database options are increasing as well — many free, open-source databases can cater to unique project needs.

    This “polygot persistence” could also simply be a natural occurrence within large enterprises supporting many application nuances. As Martin Fowler describes, “… any decent sized enterprise will have a variety of different data storage technologies for different kinds of data.”

    Quality Database Ops = Quality Software Performance

    In summary, non-relational databases are gaining steam, cloud and hybrid database models are becoming more common, and large organizations are increasingly using multiple database types. The landscape is forecasted to diversify further, meaning database DevOps is stepping up to manage this complexity.

    The report indicates a correlation between quality database Ops and overall software quality, noting that organizations that release more frequently typically deploy database changes in much less time. To achieve these goals, “… the next area for database DevOps is in the data engineering and analytics space,” writes Pramod Sadalage, director, data & DevOps, ThoughtWorks.

    While it’s important to take a vendor-endorsed study with a grain of salt, it’s safe to say we will likely see more interest in database DevOps, especially as DevOps themes continue to permeate through the entire spectrum of software development and delivery.

    For more information, you can download The State of Database DevOps report behind an email gate here.

  • Amex, Adobe Join GitHub Intern Program

    Amex, Adobe Join GitHub Intern Program

    GitHub revealed today that Adobe and American Express have joined its Summer 2021 Fellowship program, a 12-week, hands-on curriculum where interns work alongside developers to contribute to open source projects hosted on the GitHub repository.

    Vanessa Gennarelli, senior director of education at GitHub, said the overall goal of the program is increase the pool of developer talent with experience working remotely on an open source project that requires a fair amount of collaboration with other developers.

    The program was developed in collaboration with Major League Hacking (MLH), which organizes hackathons for students. Each intern participates in a series of short hackathon sprints involving multiple open source projects over the 12-week period. GitHub originally created the fellowship program as a way to address the demand for online internships during the COVID-19 pandemic.

    Those internships have provided open source maintainers with access to a pool of talent that can reside anywhere versus, for example, always trying to recruit individuals located in a specific geographic area, Gennarelli said. GitHub is also trying to increase diversity within the open source community, Gennarelli added.

    Three quarters of open source maintainers (76%) that have worked with MLH interns reported their open source project was in a better state after working with MLH Fellows. Of eligible fellows who were matched for jobs with an MLH Fellowship partner company, more than 20% ended up receiving full-time offers at that company.

    Mike Swift, MLH CEO, said the internships provide a way to partially close a gap in developer expertise that only continues to widen. Organizations are especially keen to find developers that have open source expertise, Swift added.

    A survey of 3,400 developers and technology managers conducted O’Reilly Media on behalf of IBM finds 65% of respondents preferred skills related to the underlying open source technologies. The same percentage agreed that contributions to open source projects impress potential employers and result in better professional opportunities. In many cases, open source projects are among some of the most innovative development initiatives in the IT industry, Swift noted.

    Of course, as open source becomes a primary driver for building software, more contributors are looking to get paid for their efforts. Much of that compensation comes in the form of organizations that hire developers for the express purpose of contributing to open source projects that they deem critical to their operations.

    Regardless of how developers are compensated for their time and effort, it is apparent open source projects are the fountainhead from which many opportunities spring. Future success in any endeavor has as much to do with who someone knows as it does actual talent. The best place for any developer to expand their base of industry contact is to collaborate on an open source project. The more projects they contribute to, the greater the reach of their personal network and, by extension, their net worth, will become.

  • Grafana Labs Adds On-Premises Observability Platform

    Grafana Labs Adds On-Premises Observability Platform

    Grafana Labs announced today the availability of a unified Grafana Enterprise Stack that enables IT teams to deploy a curated observability platform, based on open source tools such as Prometheus, in their own on-premises IT environment.

    Tom Wilkie, vice president of product for Grafana Labs, said Grafana Enterprise Stack, in addition to providing a version of Prometheus optimized for distributed computing environments, includes curated instances of open source Grafana dashboards, Loki log aggregation tools and the Cortex query engine.

    Grafana Enterprise Stack also includes plugins for visualizing data from other commercial tools in Grafana, such as Splunk, New Relic, MongoDB, ServiceNow, Oracle and Snowflake. In addition, it includes reporting tools and enhanced authentication and security controls.

    Grafana Labs

    Developed under the auspices of the Cloud Native Computing Foundation (CNCF), Prometheus has gained traction as a monitoring platform used primarily in Kubernetes environments. However, Wilkie said it’s only a matter of time before IT organizations expand their use of Prometheus to include a wider range of platforms. The Grafana Enterprise Stack facilitates that transition by making it easier for organizations to deploy a complete observability platform based on open source software, said Wilkie.

    While open source software has a key role to play in enabling observability, most IT organizations today rely on a range of proprietary tools to monitor IT environments. Many of those tools will be replaced, in the months ahead, by observability platforms that provide more context than individual monitoring tools currently do. However, it’s not clear yet if IT teams will prefer open source or proprietary platforms that, in most cases, incorporate open source components.

    As IT environments become more complex, the tools most organizations rely on today don’t surface enough actionable insights. Most IT teams today still waste a fair amount of time navigating amongst multiple tools in an effort to discover the root cause of a problem. It’s not uncommon for IT teams to take days to discover the source of a problem that is then fixed in a few minutes. The expectation is that observability platforms will sharply reduce the amount of time and effort required to investigate, for example, a performance issue.

    Of course, to achieve that goal, applications themselves will need to become more instrumented. A mix of open source and proprietary agent software will make it easier to collect traces, logs and other metrics at a reduced cost. In many cases, IT teams have been reluctant to fully instrument an IT environment, because of both the cost of proprietary agent software and the inherent challenges associated with deploying and managing it across an extended enterprise. However, as the deployment process for agent software becomes more automated, organizations are finding it easier to instrument their applications.

    It may be awhile before IT environments are fully instrumented. However, as it becomes easier to collect traces, logs and metrics, the level of observability that can be achieved across an enterprise will undoubtedly increase. The challenge and the opportunity then becomes employing the greater visibility provided by these platforms to manage the sprawl of applications and platforms across IT more proactively.

  • Open Source Advocates Want Share of Wealth

    Open Source Advocates Want Share of Wealth

    The egalitarian spirit of the open source community might be starting to fray as individual developers begin to question who is really benefiting most from their efforts.

    A survey of 4,440 developers who actively participated in open source projects in 2020 finds more than half (54%) of respondents said they feel that individuals should be paid for their contributions to open source projects. The report, conducted by DigitalOcean, a cloud service provider, finds only 14% of respondents are currently paid for their contributions.

    Developer opinions vary, depending on age group, about whether individuals should be paid for their contributions to open source, with those between the ages of 18-25 being more likely to be in favor (60%), while only 34% of those aged 55 or above agreed.

    “A lot more people want to be compensated,” said Raman Sharma, vice president of product marketing for DigitalOcean. “That may mean there will be a need for more sponsorships by vendors.”

    The DigitalOcean report arrives just after Elastic announced it is changing the licensing terms under which it makes Elasticsearch available. Elastic is shifting away from an Apache license to a dual license strategy that includes a server-side public license, or SSPL, along with a proprietary Elastic license. That shift was made to help ensure more of the revenue generated by Elasticsearch winds up in the hands of Elastic rather than cloud service providers, such as Amazon Web Services (AWS), that routinely launch paid services based on open source code. AWS responded to the Elastic move by announcing plans to fork Elasticsearch code that it will now curate.

    Nearly half of respondents (47%) to the DigitalOcean survey said they think technology companies should fund the payment of open source contributions, while a quarter (25%) believe project owners or individuals should pay.

    Discontent among startup vendors has been building for months. Startups typically are backed by venture capitalists, and make their software available as open source code in an effort to build a customer base on the strength of their support services. Cloud service providers have discovered they can take the code these vendors create to launch their own service. Those cloud service providers may contribute code to the project, but the startup vendor doesn’t typically enjoy any of the economic benefits.

    In most cases, the open source code used by the cloud service provider comes from a small cadre of developers that work for the startup company. Most of those startup companies are hoping to build a community around their code that includes individual contributors, external to the company, to help defray those costs. In fact, that business model has contributed to open source projects’ role as one of the primary drivers of IT innovation in recent years. If more independent developers demand to be paid for those efforts, the innovation rate of open source projects is likely to slow. The labor required to support those projects simply won’t be as freely available.

    In contrast, massive open source projects, such as Linux, have already reached a level of sustainability that other projects can only dream of. The Linux community is still ruled by Linus Torvalds, who some say is something of a benevolent dictator. Many of the contributors to Linux, however, are full-time employees working for vendors like IBM and SAP, which have a vested interest in the underlying open source platform.

    In contrast to the Linux community’s approach, the Eclipse Foundation, The Open Infrastructure Foundation (formerly the OpenStack Foundation), the Apache Software Foundation and the various arms of the Linux Foundation have stepped in to provide some level of independent governance for a wide range of open source initiatives, with mixed success. The Cloud Native Computing Foundation (CNCF), for example, as an arm of the Linux Foundation, has played a major role in spurring Kubernetes adoption. However, Google recently spurned the CNCF when it decided to create its own steering committee to oversee development of the Istio service mesh.

    Despite all the internecine rivalries and the potential for more forking of open source projects, overall, these projects are still viewed favorably. A survey of 3,400 developers, conducted by O’Reilly Media on behalf of IBM, finds 94% of respondents said they rate open source software (OSS) as equal to or better than proprietary software. Nearly two-thirds of respondents (65%) also agreed that contributions to open source projects impress potential employers and result in better professional opportunities.

    Of course, one of the primary reasons so many developers prefer open source is that there is no purchasing process for them to navigate.

    “Developers can move faster,” said Todd Moore, vice president for open source at IBM. “Programmers can move at the speed of light.”

    Regardless of motivation, it’s clear open source software isn’t going away. However, how it is built and exactly what is permissible under an open source license may soon vary much more widely from one project to the next.

  • EraDB Launches Log Management Alternative

    EraDB Launches Log Management Alternative

    EraDB today launched EraSearch to provide IT teams with an alternative to open source ElasticSearch software for managing logs at scale.

    Todd Persen, EraDB’s CEO, said EraSearch is based on a modern database that decouples storage and compute. In this way, EraSearch can scale more efficiently than ElasticSearch, while providing IT teams with the same familiar construct for managing logs.

    Persen said EraDB also uses true zero-schema data representation, and an indexing engine based on machine learning algorithms, to enable EraSearch to scale better. This approach also cuts cloud and operational costs by as much as 30% and 70%, respectively, by relying, in part, on object-based storage systems to store log data.

    As IT environments become more complex and continue to scale, organizations that standardized on ElasticSearch are discovering that a platform based on decades-old search engine technology is not keeping pace with their needs.

    EraSearch provides an alternative, based on a commercial time-series database platform that EraDB created, to address such use cases as an alternative to database platforms such as InfluxDB.

    The question is whether IT organizations, that have relied on ElasticSearch for years, are ready to abandon an open source platform in favor of a proprietary platform, even if it provides a similar user experience. EraDB, however, is betting there are enough IT organizations willing to make that shift to justify its investment in EraSearch.

    Persen said one issue with ElasticSearch is that, as log volumes increase beyond a few terabytes, the platform becomes inefficient and difficult to efficiently scale. That leads to higher costs in terms of both raw storage, as well as all the manual effort on the part of software engineers, required to maintain the platform.

    EraDB, of course, is making a classic case for a proprietary platform over an open source platform: that open source, while free, often proves more expensive to support. Persen said EraDB decided to eschew the open source model altogether, because it is too difficult to prevent nullification of the benefits open source could bring to a small company by open source project forks.

    The ElasticSearch community, meanwhile, is roiled by Elastic’s decision to change the licensing terms under which it makes ElasticSearch available. Elastic is shifting away from an Apache license to a dual-license strategy that includes a Server-Side Public License, or SSPL, along with an Elastic License. That shift was made to help ensure more of the revenue generated by Elastic search winds up in the hands of Elastic, rather than cloud service providers, such as Amazon Web Services (AWS), that routinely launch paid services based on open source code. AWS responded to the Elastic move by announcing plans to fork ElasticSearch code that it will now curate.

    Regardless of how that battle ends, however, EraDB is making it clear it views its platforms as too critical to its customers’ IT operations to get caught up in a similar maelstrom over business models and associated licensing terms.

  • New Relic Adds Visualization Tool to Observability Platform

    New Relic Adds Visualization Tool to Observability Platform

    New Relic announced today it has added a visualization tool, dubbed New Relic Explorer, to make it simpler for IT professionals to discover the root cause of issues that adversely affect application performance.

    Buddy Brewer, global vice president and field CTO for the Americas, New Relic, said the goal is to make it simpler for IT professionals to navigate and, ultimately, act on, all the metrics collected by the New Relic One observability platform.

    New Relic Explorer includes a New Relic Lookout capability that enables IT teams to drill down into telemetry data gathered from New Relic One, as well as other third-party sources, and a New Relic Navigator capability for determining the health of relationships between services, said Brewer. These capabilities make it possible to more easily identify correlations, abnormal history and traces that would be, for example, indicative of blind spots or unknown relationships between IT services, Brewer said.

    Just as importantly, IT professionals can more easily discover recent changes to an IT environment, which are most likely the cause of any new issue that is adversely affecting the IT environment, Brewer added.

    New Relic Explorer requires no configuration, and will be included as part of the existing New Relic Full-Stack Observability offering to give IT teams a single unified view of their IT environments, said Brewer.

    As IT environments become more complex, the amount of time spent looking for the root cause of an issue that might only take a few minutes to fix has substantially increased. As a result, organizations are allocating a significant amount of time to convene “war rooms” to identify the source of problems; those problems can now be more readily identified using New Relic Explorer.

    In general, Brewer said, New Relic remains committed to opening up the platform to external telemetry sources, including data collected using open source tools, such as Prometheus and OpenTelemetry agent software, both advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

    New Relic, like providers of similar tools, has recently begun repositioning itself as a provider of an observability platform, rather than of application performance management (APM) tools, that provides insights into both applications and the infrastructure on which they depend. That approach promises to provide IT teams with more context any time an issue arises. As part of that shift, New Relic is making it clear that while it views its agent source as a richer source of telemetry data, its platform can consume relevant data wherever it can be found. New Relic will also remind customers that its agent software, and the other data collection tools it provides, are simpler to install and update.

    The tradeoff, of course, is cost. While open source software itself is free, the total cost of implementing and managing that open source software can be substantial. Regardless of approach, however, the days when IT teams only applied application monitoring tools to their most mission-critical applications because of cost concerns are coming to an end. It has become impossible to manage a modern IT environment made up of both monolithic and microservices-based applications without such capabilities.

  • The Benefits of Open Source Technologies

    The Benefits of Open Source Technologies

    Over the last 20 years, we have seen the proliferation of open source software and technologies become part of commercial offerings, either as part of the technology stack that powers the product or part of the product itself. Although these two use cases are largely different, both have come to showcase just how useful open source is, not only for the developer community but for businesses as well.

    One of the benefits of working with open source technologies or projects is the free sharing of ideas. Open source brings people together to brainstorm and develop a common piece of technology. The shared love for what they do crosses cultural and geographical boundaries. One of the best-known – and arguably, most important – open source projects is the Linux kernel and operating system. Linus Torvalds released the first version of the kernel to the open source community through a mailing list, sparking worldwide collaborative development and widespread adoption.

    The passion for open source stems from a deeply rooted belief that contributors are solving an important problem, and that they are working towards the betterment of the world as a whole. In many cases, this is demonstrable. The Linux kernel now powers the majority of data centers worldwide, serving billions of users. But it’s not only that subjective passion that has played a key role in establishing open source technologies. The peer-review process of open source projects means that each code commit passes a rigorous, public audit and verification process. It has proven to be a superb way to increase code quality, reduce bugs and regressions and guard against vulnerabilities. Research has shown, objectively, that this process produces higher quality software than the standard, proprietary quality assurance and testing procedures.

    When selecting an open source technology to use in development, there are a couple of issues that need to be considered in order to safeguard the quality of your product. One key consideration is to resist chasing the latest technology fad. Instead, select the right technology for the job. It’s in developers’ DNA to obsess over new and exciting technologies, but this does not always mean that they are appropriate. While Kubernetes may be the right solution if you need to serve millions of users at Netflix-like scale while managing maintenance and cost, it likely isn’t the best choice for a new startup launching the first iteration of their product. In this case, speed of development and flexibility to make changes is more important than scalability (so, perhaps, the startup might be better off using Ruby on Rails or Django). These three projects all share an important characteristic: They have active communities that not only safeguard project features but also maintain them and offer peer-to-peer support.

    When implementing a new feature with a particular technology, this supporting community is very important, since they can greatly accelerate the development of your product. These are people who love what they do and want to see other community members succeed with the technology. In this regard, it’s also important to consider giving back to the projects and communities you benefit from. You can either participate in the communities and help others yourself, one-on-one, or contribute by sharing the improvements that you have made to the open source technology. If you have extended the API, for example, or discovered and fixed bugs, there is no reason not to contribute your changes back and further enrich the ecosystem. The credibility you build in this way can also be a benefit, as people will identify you, your team and your product as supporters of the open source project. It’s a virtuous cycle of collaboration with benefits that should not be underestimated.

    As you and your product become an important part of the open source ecosystem, either because you use open source components or because the core of your product is open-sourced, remember that trust is notoriously hard to build and very easy to lose quickly.

    Whatever one’s feelings are on this matter, the open source community is very careful about who they trust and can easily be alienated by a company that appears not to have their best interests in mind. In order to build trust, it’s important for teams to build credibility. Open source communities are largely merit-based, so unless the community sees proof of expertise and knowledge, they will not automatically trust a self-proclaimed expert. This credibility can even extend to the personal, like the many open source developers who have a large following on social media and lend their credibility to the projects and companies that they work for.

    Finally, when dealing with open source technologies, projects, and communities, it’s key to remember that developers are very sensitive to blatant sales pitches. Authenticity matters in the way that a project, company or brand presents itself. Open source is all about collaboration and community; it’s a relationship built on trust and mutual benefit, not profit.

  • Oracle Includes GraalVM Support in Java SE Subscription

    Oracle Includes GraalVM Support in Java SE Subscription

    Oracle announced today it is adding a GraalVM Enterprise virtual machine for building Java applications to Java SE Subscription at no additional cost.

    Donald Smith, senior director of product management from the Java Platform Group at Oracle, said GraalVM Enterprise provides developers with a high-performance application runtime, built on Oracle Java SE, that includes a compiler that accelerates Java application execution. That’s critical as developers look to build microservices-based applications employing microservices that tend to be latency sensitive, Smith said.

    The first stable release of GraalVM arrived last fall. It consumes less memory, and enables Java applications to spin up faster by taking advantage of capabilities such as a just-in-time compiler. GraalVM Enterprise adds a native image utility that compiles Java and JVM-based applications ahead-of-time (AOT) into self-contained native executables. That approach only includes the classes and libraries needed to run the application, which reduces the size of the binary that gets generated.
    Including GraalVM Enterprise in the Java SE Subscription make it easier for Java developers to switch to that Java virtual machine (JVM) to build microservices rather than having to learn another language, Smith said.

    Smith said most organizations will continue to build monolithic applications at the same time they’re attempting to construct microservices. The Java SE Subscription makes it possible for developers to employ different JVMs depending on the type of application being constructed or updated, Smith said. A survey of 560 developers conducted by Oracle last month finds nearly half (48%) are already employing GraalVM to build microservices using Java.

    How much will organizations rely on Java to build microservices, given all the other programming language options available? That’s up for debate. However, being employed in the enterprise for more than 25 years, the number of developers that know Java well is substantial. Rather than waiting for those developers to become proficient in another programming language, there’s a natural tendency for organizations to want to stick with a familiar language. Each additional language introduced to build applications also tends to complicate DevOps processes in a way that can increase the total cost of IT.

    At the same time, however, the number of developers that know how to develop applications using everything from JavaScript to Go is also increasing. Oracle, via ongoing investments made in the OpenJDK project, is moving to make sure Java stays relevant at a time when the number of programming languages being employed has never been greater. For what it’s worth, GraalVM is designed to support multiple programming languages, including JavaScript.

    It’s unlikely Java will fade into obscurity any time soon. IT organizations have a vested interest in embracing next-generation JVMs, if for no other reason than making Java applications more efficient, regardless of how they are built.

    It’s also worth mentioning that frameworks – such as Quarkus from Red Hat – that enable Java-based microservices to run natively on Kubernetes clusters already rely on GraalVM. In some cases, developers may wind up employing such a framework without realizing it relies on GraalVM. In other cases, the challenge will be getting developers to opt for GraalVM as their JVM of choice when so many of them have routinely used the same JVM for more years than they care to admit.