devopsy.kinsta.cloud

Category: Blogs

  • The Cloud Is Booming — But so Is Cloud Waste

    The Cloud Is Booming — But so Is Cloud Waste

    Fueled by the growth in cloud spend, cloud waste will exceed $17.6 billion in 2020.

    Over 90% of organizations will use public cloud services this year. In fact, public cloud customers will spend more than $50 billion on Infrastructure as a Service (IaaS) from providers such as AWS, Azure and Google. This boom is, of course, due to the broader adoption of public cloud services. But, it is also caused by the expansion of infrastructure within existing accounts. Not surprisingly, the growth in spending often exceeds the growth in business. That’s because a huge portion of what companies are spending on cloud is wasted.

    Cloud Computing Is Expanding

    Before getting to the waste, let’s look a little closer at the growth in the cloud sector. Gartner recently predicted that cloud services spending will grow 17% in 2020 and will reach $266.4 billion. While Software as a Service (SaaS) makes up the largest market segment at $116 billion, the fastest growing portion of cloud spend will continue to be IaaS. This will increase 24% year-over-year and surpass $50 billion in 2020.

    Typically, I find that about two-thirds of the average enterprise public cloud bill is spent on compute, which means about $33.3 billion this year will be spent on compute resources. Unfortunately, this portion of a cloud bill is particularly vulnerable to wasted spend. 

    Cloud Waste Is Also Expanding

    As cloud computing growth continues and cloud users mature, we might hope that this $50 billion is being put to optimal use. While I personally do find that cloud customers are more aware of the potential for wasted spending than they were just a few years ago, this does not seem to be correlated with cost optimized infrastructure from the beginning. The fact is, it’s simply not a default human behavior. 

    I frequently run reports for companies having issues with cloud waste. Invariably, I find wasted spend in these accounts. For example, one healthcare IT provider was found to be wasting up to $5.24 million annually on their cloud spend—an average of more than $1,000 per resource per year.

    Below is where the total waste is coming from.

    Idle Resources: Idle resources are VMs and instances being paid for by the hour, minute or second, that are not actually being used 24/7. Typically, these are non-production resources being used for development, staging, testing and QA. Based on data collected from our users, about 44% of their compute spend is on non-production resources. Most non-production resources are only used during a 40-hour work week, and do not need to run 24/7. That means that for the other 128 hours of the week (76%), the resources sit idle, but are still paid for.

    So, I find the following wasted spend from idle resources: $33.3 billion in compute spend, times 0.44 non-production, times 0.76 of week idle, equals to $11 billion wasted on idle cloud resources in 2020.

    Overprovisioned Resources: Another source of wasted cloud spend is overprovisioned infrastructure—that is, paying for resources are larger in capacity than needed. That means you’re paying for resource capacity you’re rarely (or never) using. About 40% of instances are sized at least one size larger than needed for their workloads. Just by reducing an instance by one size, the cost is reduced by 50%. Downsizing by two sizes saves 75%.

    The data I see in client infrastructure confirms this—and the problem may well be even larger. Infrastructure I see has an average CPU utilization of 4.9%. Of course, this could be skewed by the fact that resources I deal with are more commonly for non-production resources. However, it still paints a picture of gross underutilization, ripe for rightsizing and optimization.

    To take a conservative estimate of 40% of resources oversized by just one size, we see the following: $33 billion dollars in compute spend, times 0.4 oversized, times 0.5 overspend per oversized resource, equals to $6.6 billion wasted on oversized resources in 2020.

    The Extent of Wasted Cloud Spend

    Between idle and overprovisioned resources alone, that’s $17.6 billion in cloud spend that will be completely wasted this year. In fact, it could well be higher. Other sources of waste include orphaned volumes, inefficient containerization, underutilized databases, instances running on legacy resource types, unused reserved instances and more. Some of these result in significant one-off savings (such as deleting unattached volumes and old snapshots) whereas others can deliver regular monthly savings. 

    That’s a minimum of about $5 million wasted per day, every day this year, that could be reallocated toward other areas of the business. 

    It’s time to end wasted cloud spend. Perhaps acknowledging the extent of this problem is a good first step.

    — Jay Chapel

  • HashiCorp Updates Terraform Tool for Azure Cloud

    HashiCorp Updates Terraform Tool for Azure Cloud

    HashiCorp today announced it has updated the instance of Terraform it created to automate the configuration of virtual machines on the Microsoft Azure cloud to give IT teams more granular control.

    Version 2.0. of Terraform (TF) AzureRM Provider will allow IT teams to separately configure virtual machines by type for instance of both Windows and Linux.

    In addition, version 2.0 of TF AzureRM Provider will allow users to specify custom timeouts for resources. Previously, timeouts were set for one hour by default.

    Finally, TF AzureRM Provider 2.0 removes resources, data sources and fields that have been deprecated. TF AzureRM Provider currently provides access to 374 resources and 119 data sources.

    Amith Nair, vice president of product marketing for HashiCorp, said the goal is to provide IT teams with a set of tools for automating the configuration of virtual machines on Azure that is more accessible than the tools currently provided by Microsoft.

    Nair said HashiCorp is seeing increased adoption of Microsoft Azure, which in turn creates demand for tools that make it easier to deploy virtual machines at scale. In fact, Nair notes that as more workloads move into the public cloud the less resistance there is to IT automation as administrators look for ways to manage IT at what is now unprecedented scale. Of course, many organizations gain their first experience with tools such as Terraform when they first embrace a set of best DevOps practices.

    Less clear is how many virtual machines are being configured on top of instances of Windows versus Linux. There is no doubt Microsoft has emerged as the strongest challenger to the dominance of Amazon Web Services (AWS) in the public cloud. Much of that success, however, comes from the fact that Microsoft supports distributions of Linux alongside Windows Server on the Azure cloud. There are, of course, many organizations, such as Walmart, that prefer to standardize on Azure simply because they view Amazon to be a competitor. At the same time, however, there are many companies that employ both AWS and Azure.

    Nair said most organizations that have adopted more than one cloud tend to manage them in isolation from one another. However, it is expected that one day more organizations will seek to unify the management of multiple clouds within the context of a truly hybrid cloud computing environment as the total cost of cloud computing continues to rise with each additional workload deployed. Naturally, many of those organizations eventually will gravitate toward tools that can be employed across multiple clouds.

    In the meantime, whether it’s IT administrators or developers themselves configuring virtual machines in the cloud, it’s thanks to tools such as Terraform that the amount of time and effort required to set up virtual machines in the cloud is now as negligible as it is. The challenge now is not so much finding tools to automate IT as much as it is navigating all the cultural changes that naturally ensue.

    — Mike Vizard

  • Survey Sees Open Source Adoption, Quality Gains

    Survey Sees Open Source Adoption, Quality Gains

    A survey of 959 IT leaders published this week by Red Hat finds increased reliance on and adoption of open source software is now being driven by perceived higher quality as much as it is cost concerns.

    The survey finds higher quality of software (33%) was the top reason they chose open source, followed by lower total costs of ownership (30%) and better security (29%).

    Gordon Haff, a technology evangelist for Red Hat, said the survey makes it clear that open source adoption is now being driven from the top-down as well as the bottom-up in most organizations. What’s changed is that open source software is now being used more broadly as more organizations appreciate how open source approaches to building software not only lower costs but also improve overall quality.

    The survey identifies the top three use cases for employing open source software to be IT infrastructure modernization (60%), application development (53%) and DevOps (52%).

    As part of that shift, 56% of respondents said they plan to increase usage of containers over the next 12 months. In fact, on average respondents said cloud-native applications already make up 25% of their portfolio, compared to an average of 36% for cloud-enabled applications and 39% for legacy applications. The combination of cloud-native and cloud-enabled applications (61%) already outnumber legacy applications (39%).

    Over the next two years, 47% of respondents plan to either modernize (17%), rearchitect as cloud-enabled (16%) or rearchitect as cloud-native (14%) their legacy applications. Another 16% said they would sunset or decommission those applications.

    Overall, the survey finds there has been a marked shift away from proprietary software. Only 42% said that more than half of the software they use today is proprietary, down from 55% a year ago. Two years from now only 32% said they expect proprietary software to account for more than half their portfolio. On average, respondents said 36% of their organization’s software is open source, which in two years is expected to increase to 44% in two years. A total of 77% said they would increase usage of open source software over the next 12 months.

    However, barriers to adoption of open source software remain. Security of the code (38%), level of support (37%), compatibility (34%) and lack of internal skills (33%) were all cited as ongoing issues.

    The top three areas in terms of infrastructure where enterprise open source solutions are being used today are security (52%), cloud management tools (51%), database (49%) and big data analytics (47%). A total of 83% said open source has been instrumental in their organization’s ability to take advantage of cloud architectures. Almost two-thirds (63%) said they have a hybrid cloud infrastructure environment today. Among the 37% that don’t, more than half (54%) plan to have a hybrid cloud infrastructure environment within the next 24 months.

    It’s apparent that open source software is now everywhere. The real challenge now is finding a way to manage it all.

    — Mike Vizard

  • Collaboration Over Competition: How Companies Benefit from Open Innovation

    Collaboration Over Competition: How Companies Benefit from Open Innovation

    More and more technology companies are adopting open innovation initiatives. This is largely due to the realization of the benefits of working with outside experts to gain external perspectives and insights. This situation wherein an organization thinks beyond its internal resources for innovation and collaborates with external resources is known as open innovation. Open innovation is an opportunity for the company to utilize those external ideas and use them to develop innovative products and services. It may seem simple, but there is more to the collaboration process than just brainstorming.

    Open innovation is not easy, but the benefits are well worth the effort. Large technology organizations can establish a competitive advantage by partnering with promising startups. The startups benefit from this partnership by gaining access to venture capital resources, networking opportunities and the opportunity to reach a broader customer base, typically tied to a large company.

    Larger companies that typically change at a glacial pace can learn from their small yet evolving partners. Startup founders who are new to an industry can form valuable relationships and gain mentors with seasoned veterans.

    Overcoming Obstacles

    Technology organizations, large and small, should be prepared to make some changes in order to benefit from an open innovation environment. Indoctrinating an attitude of information sharing can be difficult in companies that have historically kept their intellectual property under wraps, and in many companies, even developing a collaborative environment across various departments can be an uphill battle.

    Breaking down barriers and overcoming this predisposition toward secrets is the only way to cultivate a collaborative environment. Ultimately, this effort begins in the boardroom. Once a large company has executive buy-in, the idea will begin to trickle from the top down, and over time it will take hold.

    The following steps will serve as important guidelines to tackle obstacles and sustain this synergy.

    Create Ecosystems Around Intellectual Property

    It is common for both parties to feel the need to protect their intellectual property, but that closed mindset defeats the purpose of an open innovation initiative. To overcome this obstacle, it is critical to emphasize the greater value and benefits that come from an open innovation ecosystem. All parties must realize that sharing their intellectual property into the ecosystem can accelerate the pace of innovation.

    Several companies have demonstrated the value of this approach. Tesla, for instance, made the decision to open source its patents a few years ago, recognizing that the company couldn’t make electric cars fast enough to slow the global carbon crisis. Elon Musk also pointed out that patents represented a small protection indeed against a determined competitor, and he thought the decision to open source would strengthen the company’s position.

    Assess Your Partners

    Adding a collaborator to your open network should not be a decision that is made lightly. The organization should be patient and cautious when selecting a potential partner. Weigh each company’s skills and capabilities and consider any disadvantages as well. Just because a partner is not perfect does not mean it is not the best choice, but knowing its weaknesses will help you address them before they become a problem.

    An organization should be assessing several prospective partners. Establish processes that ensure each potential collaborator is examined fairly, but critically so that the end goal to identify the companies that will not be a good fit is achieved. This practice is not just for your benefit alone—an unproductive collaboration can incur in heavy costs and wasted time to all parties involved.

    Adjust Business Models as Necessary

    Business models are designed to maximize benefits and minimize risks, but they should allow for some flexibility. In the real world, changes arise frequently, and business models must adapt. For instance, many partnerships established around open innovation initially began between two companies. Over time, it is a reasonable expectation to anticipate other players be added to the mix.

    A multi-dimensional ecosystem demands a different business model than a version that is two-dimensional because it may involve a different set of risks. It also has a more complex intellectual property pipeline where contributions and evolutions are more difficult to track and manage. As long as each partner is prepared to adjust business models, these changes can be effectively addressed.

    Foster a Collaborative Culture

    For the vast majority of companies, open innovation is not an organic process. Even within an organization, some departments tend to be closed off about their projects or even sharing information outside the company. An attitude of open innovation comes from internal change, and people are naturally resistant to change. To encourage a culture-shift, start from the top down.

    Support from leadership is critical for developing a culture that is compatible with open innovation. It is also important to identify the soft skills that a team needs to accomplish its goals. Open innovation itself is a skill that can be taught—problems arise when company executives expect it to be a trait that employees are inherently born with.

    There are numerous benefits of open innovation. Technology companies can produce more ideas in a shorter span of time mutually benefiting all businesses involved. There is an opportunity to create markets that did not exist prior to the development of the initiative.

    Of course, obstacles are also inevitable and more so because sharing valuable intellectual property outside the confines of a research and development department is always looked down upon. People, and business models, are naturally resistant to the significant change that comes with the open innovation approach. Whether a company can overcome these obstacles and see the many advantages is a matter of determination and a desire to adopt company-wide changes so that there is innovation across the organization.

    — K.R. Sanjiv

  • Report Pins Cloud Security Woes on Flawed DevOps Processes

    Report Pins Cloud Security Woes on Flawed DevOps Processes

    By now it’s become apparent that the bulk of security incidents involving cloud platforms revolve around some type of configuration issue. An analysis of those cloud configurations published today by the Unit 42 research arm of Palo Alto Networks suggests that the root cause of the issue is most likely the templates many developers and DevOps teams rely on to configure cloud infrastructure. In fact, according to Unit 42’s analysis, more than 199,000 templates have medium-to-high vulnerabilities in use on public clouds.

    Matt Chiodi, chief security officer for public cloud for Palo Alto Networks, said the issue stems from the rate at which organizations now want to be able to deploy applications on public cloud. Templates greatly accelerate the process but very few of those templates have been vetted by a cybersecurity team.

    According to the report, the most commonly used templates are created using YAML files on instances of Kubernetes (39%), Terraform and CloudFormation (24%). The most vulnerabilities were discovered in templates created using CloudFormation (42%), Terraform (22%) and YAML for Kubernetes (9%).

    Chiodi noted most templates are created through a simple three-step DevOps process: design, code and deploy. Unfortunately, in the rush to deploy most DevOps teams forget to scan for vulnerability issues. As a result, Chiodi said cybercriminals have become very adept at siphoning off cloud resources to mine cryptocurrencies at low-enough consumption rates to go unnoticed by many IT organizations.

    Other significant cloud security issues surfaced in the report include the fact that 43% of cloud databases are not encrypted and that 60% of cloud storage systems have logging disabled, which Chiodi noted makes it impossible to know whether those systems have been compromised. In addition, the report finds 76% of cloud workloads expose SSH (port 22), while 69% of organizations expose RDP (port 3389) and 27% are using outdated versions of Transport Layer Security.

    Overall, the goal now needs to be to make it as simple as possible for DevOps teams to do the right cybersecurity thing going forward, said Chioti.

    Unit 42 researchers employed a publicly available GitHub Searching application programming interface (API) to find AWS CloudFormation files, Kubernetes YAML files and HashiCorp Terraform files. Hundreds of thousands of templates were then downloaded and analyzed by the Prisma Cloud infrastructure-as-code (IaC) Scanner to identify the insecure configurations. Each IaC file was also sent to an IaC resource checker to analyze the cloud resources being used in the template. Researchers also used Palo Alto Network’s proprietary AutoFocus and Wildfire tools to identify and investigate cybercrime groups through their usage of custom toolsets (malware samples). Those samples were dynamically and statically analyzed to ensure indicators of compromise.

    The Unit 42 research makes it clear there’s a lot of room for improvement when it comes to employing best DevSecOps processes in the age of the cloud. The challenge, however, may have little to do with the tools available. Rather, it’s the absence of a structured set of processes through which DevOps teams and cybersecurity professionals can collaborate that appears to be inflicting the most damage.

    — Mike Vizard

  • 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

  • Latest Chef Habitat Release Embraces On-Premises IT

    Latest Chef Habitat Release Embraces On-Premises IT

    Chef today announced that the Chef Habitat automation framework for building and deploying applications can now be used in on-premises IT environments.

    Mike Krasnow, a senior product manager for Chef, said version 1.5 of Habitat makes it possible to now store applications packages and their dependencies locally in addition to the cloud. In addition, pre-built application packages and dependencies from the Builder service can be deployed across multiple on-premises instances.

    An Applications tab in Chef Automate now shows the service groups and instances that are deployed to make it easier to understand what’s deployed where and the health of each service. Both the Habitat Builder installer and the application dashboard are integrated with Chef Automate, which uses the same installer as Chef Habitat.

    Finally, the Habitat Supervisor module is now more stable, easier to configure and manage, and provides improved support for Windows applications.

    Krasnow said Chef has seen a 300% increase in the use of the software-as-a-service (SaaS) instance of Chef Habitat in the last year. Organizations that have embraced Chef Habitat include Alaska Airlines, Rakuten, and Walmart. That rate of adoption should increase now that an on-premises edition is available, he said, including among IT organizations in highly regulated industries that are not allowed to employ cloud services. In fact, at least 70% of all application workloads are still deployed in on-premises IT environments.

    Chef Habitat appeals most to organizations that have embraced best DevOps practices to programmatically deploy applications, said Krasnow. There are rival automation platforms that make use of declarative approaches to automation that appeal more to IT generalists. However, he noted, organizations that want to empower DevOps teams tend to prefer a more programmatic approach.

    For more than a decade now Chef has been driving adoption of IT automation. However, it’s only relatively recently that organizations have been employing IT automation at scale as part of their efforts to embrace best DevOps practices. As interest in IT automation frameworks has risen, so too has the number of options. Some organizations are even employing multiple IT automation frameworks within different business units. They may one day standardize on a single IT automation framework, but many DevOps teams will simply opt to employ the IT automation framework the members of their team already know. If the members of that team in charge of IT operations don’t have a lot of programming expertise, chances are high they will opt for a more declarative approach. DevOps teams that have developers who deploy applications on their own are likely to prefer a more programmatic approach.

    Regardless of the platform chosen, it’s clear the days of manually deploying applications using custom scripts are coming to an end. IT organizations now require an industrial approach to managing IT as a factory. The biggest challenge achieving that goal is no longer the technology but rather the culture of the IT organization.

    — Mike Vizard

  • The Risks and Potential Impacts Associated with Open Source

    The Risks and Potential Impacts Associated with Open Source

    Open source software (OSS) is built by communities of developers who contribute their knowledge and time to OSS projects they find appealing. That code can then be used by individuals, communities and organizations in their software products—the only obligation they have is to play under the rules of the license with which the OSS project was published. 

    This type of knowledge sharing brings many benefits to OSS users as it speeds up software development time and can help companies become more competitive in the market. Unfortunately, there is also a catch. Those benefits also come with certain risks which every OSS user needs to be aware of and take necessary actions to mitigate.

    The OSS License

    One specific risk to consider involves the OSS license. Not knowing what your obligations are under the license (or not abiding by those obligations) can cause an OSS user to, for example, lose intellectual property or experience a monetary loss.

    Operational Impact on the Product

    Another risk is the operational impact that the OSS in use will have on the product. It’s important to understand whether the community is consistently managing the OSS project and its issues in a timely manner, and that your organization has implemented the latest version and deployed patches have been applied. Using out-of-date, unpatched or unmaintained OSS could impact your release capabilities, product quality and customer trust.

    Security Vulnerabilities

    The third risk to consider when using OSS is that of security risk. As open source is software—and in many cases very complex software—it brings with it the possibility of introducing software security vulnerabilities into your source code. Some vulnerabilities can be introduced into your projects through dependencies that the OSS your organization is using has on other OSS projects. Additionally, vulnerabilities could be unintentionally introduced by developers as they code a functionality using open source. The reason for this is that software developers, whether professionals or hobbyists, oftentimes do not consider security while coding. This has a substantial impact on their work and their contributions to open source projects. 

    It’s not necessarily that developers intentionally skip the implementation of security procedures. Secure coding is a specific discipline in software development that guards against the accidental introduction of vulnerabilities—a discipline that must be learned. 

    Understand that many developers are self-taught or have been trained in schools and universities (where we are only recently seeing courses in software and application security emerging). Many use their software development skills as a hobby, to contribute to OSS projects or to pursue their own personal projects. Unfortunately, training programs, programming courses in schools and online tutorials often neglect to convey this knowledge or to stress the importance of building secure software. 

    It’s also important to note that many organizations find it difficult to introduce a secure coding discipline into their software development process. In other words, this struggle persists beyond open source projects. If you’re with an organization experiencing this pain point and unsure where to begin, you’ve come to the right place. There are several strategies that can be used to begin your secure coding journey. 

    Training

    By giving developers the education required for them to become security aware, you’re setting them up for consistent, secure development success. There are a variety of in-person and computer-based training options on the market.

    Software Composition Analysis (SCA) Tooling

    Implementing an SCA tool will uncover incorrectly coded strings or vulnerabilities that have been introduced in code or OSS components. Not only can SCA tools assist developers in identifying potential software risks, some SCA solutions can help to train developers by offering remediation guidance or short training videos on how to avoid such vulnerabilities in the future.

    It’s essential for software issues to be discovered early because the deeper into the process they’re identified, the more time-consuming and costly they are to remediate. As such, in recent years there has been a push to shift left, introducing security into the product development life cycle from the very beginning. 

    Companies and individuals need to also understand that this security mindset doesn’t start and end in the coding phase of the development process. A security mindset needs to be a part of every phase: from design to deployment to maintenance, all the way through to the product’s end of life. 

    Emphasizing a security mindset also has a long-term, broad reaching positive effects on the whole software development ecosystem, including the OSS world. As developers are trained to code securely (through university courses and other training institutions, coding portals or professional development through their employer) they pass this knowledge on to the projects with which they’re involved. This then leads to the production of higher quality proprietary and open source software, which in turn minimizes risk across the board.

    — Boris Cipot

  • Red Hat Extends Runtimes Middleware Portfolio

    Red Hat Extends Runtimes Middleware Portfolio

    Red Hat has made available the latest instance of Red Hat Runtimes, a suite of lightweight open source components and frameworks that makes it easier to discover the middleware most appropriate for building a specific type of application.

    James Falkner, product marketing director for Runtimes at Red Hat, said as organizations embrace cloud-native application architectures based on microservices it’s become increasingly challenging to determine what middleware to deploy optimally and where. Red Hat Runtimes not only makes it easier to navigate all those options, Falkner said, but all the components and frameworks are certified to be pre-integrated.

    The latest version of Red Hat Runtimes adds support for Open Liberty, a lightweight runtime for building Java applications developed by IBM. Red Hat was acquired last year by IBM.

    The latest installment of Red Hat Runtimes also provides access to what has become a standard distribution of Node.js based on Red Hat Software Collections that will be implemented across all Red Hat offerings.

    Finally, Red Hat has also added support for Red Hat Single Sign-On, an access control framework based on the Keycloak project.

    Falkner said Red Hat Runtimes also serves to reduce the total cost by providing a single subscription through which organizations can access everything from container runtimes to the 3Scale application programming interface (API) management middleware, which Red Hat acquired in 2016.

    Very few IT organizations these days are standardized on a single class of middleware, especially as they embrace microservices-based applications built using containers. Most IT teams for the foreseeable future will need a flexible way to access multiple runtimes in support of everything from monolithic applications based on Java to applications built using Node.js code deployed using Docker containers.

    Rather than a piecemeal approach to the middleware infrastructure required to build, deploy and integrate all those applications, Falkner said Red Hat Runtimes provides a more holistic approach.

    It’s not clear how much or even whether IT organizations are centrally managing middleware in the age of DevOps and the cloud. Historically, many IT organizations preferred to standardize on a single application server platform to deploy various classes of middleware. However, many developers today are deciding what middleware to include within their application stacks without much input from a central IT function.

    Via Red Hat Runtimes, Red Hat is trying to make a case for providing developers with the flexibility they cherish in the form of a subscription service that provides IT teams with a modicum of control over what middleware gets employed.

    Tensions between DevOps teams and central IT organizations have arguably never been higher. In fact, many DevOps teams are operating within lines of business that are outside the direct control of centralized IT. As such, the level of standardization that can be imposed by central IT organizations has become more constrained. Many centralized IT organizations are now trying to influence middleware platform decisions rather than outright make decrees that might get ignored anyway.

    Regardless of the middleware platform choice that ultimately gets made, however, the one thing that most centralized IT teams will have to come to terms with is finding a way to support it.

    — Mike Vizard

  • Trends and Benefits of Serverless Computing

    Trends and Benefits of Serverless Computing

    Gartner estimated that by 2020, 20% of the world’s organizations will have gone serverless. Serverless computing initiates a mind shift in the way businesses are run and improves the accuracy and impact of technology services. Leading to higher functionality, reduced AWS bills, increased delivery speed and multi-cloud support, serverless computing paves the way into the future. 

    The scope of serverless is yet unexplored. With new and high-potential developments (such as FaaS and GitOps) still in their nascent stages, organizations can expect massive benefits leveraging the power of serverless computing going forward. 

    Servers have been a very important part of the computing architecture for decades. But, with the introduction of cloud, we’ve moved to predominantly web-based server infrastructure, and the migration to serverless architecture has begun.

    Serverless computing–abstract and virtual server support–has made the computing landscape more dynamic, robust, intuitive and powerful. But advancement in serverless technology is still in its nascent stage. The next few years are expected to bring in numerous developments and transformations.

    First, let’s take a look at some serverless trends you should keep an eye out for.

    Kubernetes Will Become the Go-to Serverless System

    Kubernetes has become synonymous with open-source containerization. But in the next few years, we will see Kubernetes become the base for serverless infrastructure. Features such as networking, service discovery, agile scaling and multi-cloud environment support make Kubernetes the perfect choice for serverless. 

    Additionally, with Knative already released, the process of standardization and interoperability of serverless platforms may soon become a reality. 

    Stateful Applications Will Also See the Usage of Serverless

    Restriction of serverless for stateless apps is a thing of the past. The next few years will see stateful apps benefiting from the immense power of serverless. Developers will be able to use database connections, BaaS and event payloads to run their applications.

    FaaS Industry Size Will Grow 

    The FaaS market is expected to grow to $7.72 billion by 2021. Large-scale adoption of serverless will be seen across the world, and there will be a 32.7% CGAR. 

    GitOps Will Be the Next Big Thing 

    The version-controlled system of DevOps, GitOps, will see more takers in the future, especially in FaaS. GitOps is expected to improve operational workflows, especially in fast-moving projects, and enable implementation of technologies such as Kubernetes and other cloud solutions. 

    Additionally, this will enable cloud vendors to provide greater ecosystem support and tooling capabilities to users.

    Containers Versus Serverless

    Containers by nature are segmented, isolated and contained spaces of application-specific servers. While they offer high degrees of specialized (and often customized) tools, resources and support, they suffer from numerous challenges:

    • They are very resource-inefficient compared to serverless. 
    • Their ecosystem is fractured as opposed to the wholesome environment offered by serverless. 
    • Data storage and retention are complicated, necessitating frequent data migration across containers. 
    • Graphics support is limited, resulting in poor-quality deployments. 

    The challenges that come with containers prompt organizations to choose serverless. Already, many companies have implemented serverless.

    Here is how the move to serverless will benefit you, too.

    Serverless Computing Eliminates the Need for the Set-Up of Complex Application Stacks

    Developing even the most basic server-bound application is a challenging task. It requires the set-up of high-powered and complex application stacks that can be both difficult to build and difficult to manage. By going serverless, organizations can eliminate all these heartaches. 

    Serverless stacks, such as Lambda and Azure, create a robust and intuitive environment for the development of agile applications, by providing organizations with a large set of capabilities and allowing them to run at scale, at the lowest costs.

    It Reduces the Organization’s Capital Expenditure

    Unfortunately, IT infrastructure is considered a capital expenditure by many organizations. So, building your own servers can lead to a high CapEx.

    Consider this. Physical servers are vulnerable to breakdown and depreciation, which add to CapEx. If you report this value as expenses in your income statement, it may ultimately negatively affect your P&L and your company valuation. Going serverless allows organizations to avoid such a challenge and maintain their profitability and high valuation.

    Plus, serverless infrastructure reduces the need for human resource deployment as focus on batch processing decreases. Additionally, serverless allows organizations to convert workflows into step functions, which reduces the number of EC2 and SWF issues. Together, these reduce company expenses tremendously. 

    It Shortens the Standard Release Cycle Significantly Due to Microservices and Nano-Services

    Serverless computing allows organizations to benefit from the magnificent power and scope of microservices. From making minute application-specific developments to isolating and rectifying issues, to managing and deploying individual applications, organizations can do a lot of things using serverless computing. 

    In fact, a survey shows that utilizing serverless microservices can bring down the standard release cycle from 65 days to a mere 16 days.

    It Allows Easy Completion of ELT Tasks and Cron-Type Jobs 

    Again, serverless computing microservices gives organizations the flexibility, technical support and clarity needed to process data. ELT tasks become more consistent and allow the creation of structured data warehouses.

    Similarly, since isolated components and applications can be created, deployed and fixed in serverless, it’s easier to implement cron-type jobs as well. 

    It Allows Organizations to Escape Traditional Workflows Through Event-Based Computing 

    Adoption of serverless computing allows organizations to shift from the restrictive, time-consuming and draining traditional workflows and engage in event-based computing. Now, coders can just write the algorithms and allow the serverless provider to take care of the data storage and computing needs. Not only will this reduce the time of transaction processing and the cost of DevOps, but it will also free up the time and space for coders to take on other business logic tasks. 

    It Enables Green Computing 

    With climate change becoming such an imminent threat to the world, it’s important for organizations to become mindful about the way they operate. One way to become sustainable is to go serverless.

    For one, serverless computing ensures organizations don’t over-utilize electricity. Additionally, with no physical servers and data centers that emit toxic radiation as they cool down, there will be lesser concerns about health and climate change. 

    Another aspect is scalability. Serverless is highly-scalable, meaning you don’t need to set-up more servers at your office. Given that 30% of the world’s servers are unused at any point in time and most servers only utilize 5%-15% of their total capacity, serverless may be the best way to go green.

    It Promotes Deployer Autonomy and Encourages the Adoption of New Mindsets

    Serverless computing gives organizations the freedom to focus on their core business offerings and deal with only low-level OS issues. This time, money and opportunity can be used by deployers, coders and top management to develop competitive offerings, which can help the organization overtake competitors. 

    With physical servers, it’s more likely than not for organizations to focus on technical server issues than the business process.

    Conclusion

    Serverless computing could be one of the most exciting developments of the 21st century. It is breaking down old barriers and allowing organizations to expand and explore new frontiers. Its high deliverability, coupled with the immense opportunities it promises, makes it a must-adopt in any organization.

    — Subramonian