staging-devopsy.kinsta.cloud

Category: DevOps Toolbox

  • Introduction to Flutter

    Introduction to Flutter

    Flutter is a development tool for creating cross-platform applications. Flutter was created by Google to help developers create frontends that run on almost any operating system, including Android, iOS, Mac, Linux, Windows desktop and the web.

    Ready to check it out? You’ll first need to install the Flutter software development kit (SDK).

    Installing Flutter

    To use the Flutter SDK, you need to have git installed on your computer; here are some tips for installing it based on your OS:

    • Windows: Download it here.
    • Mac: Although you can install Git manually, your best bet is to simply install Xcode, which includes Git; you’ll need XCode later.
    • Linux: In addition to Git, you’ll need several other tools listed here. If you’re using Ubuntu or Debian, you can get them all with this single command: sudo apt install git zip unzip curl xz-utils libglu1-mesa
    • ChromeOS: This option requires you to enable Linux on ChromeOS. Then you’ll want to install the same packages that I just listed for Linux.

    After the above prerequisites are met, you can download Flutter by going to this link.

    You can either download the SDK for your operating system or you can obtain it from GitHub. Only attempt the GitHub option if you’re familiar with cloning Git repositories.

    In this example, I’m going to download the Windows version by clicking the Windows link, which brings up the screen shown below. For Windows in particular, pay close attention to the warnings about where to install the SDK. (I like to have a folder called c:\dev where I put all my dev work, and under that a folder called c:\dev\tools. So the latter is the folder where I’ll put the SDK.)

    After the file is downloaded, extract it to a location such as c:\dev\tools.

    For Windows, Linux and ChromeOS, the next step is to update your path so that the system can find the tools found in the Flutter folder’s bin folder. (Mac users don’t need to do this step.) The Flutter installation docs are helpful here:

    • Windows: Make sure you use the full path, starting with the name of the folder you extracted the zip file into. For example, on my machine, that would be C:\dev\tools\flutter\bin, as shown in the image below. Then after you update the path, you’ll need to close and reopen your command-line shell (either Windows CMD or Powershell). For detailed instructions, go here.
    • Linux: Follow the instructions here.
    • ChromeOS: Follow the instructions here.

    Now test out the Flutter command to make sure it works by going to a folder outside of the Flutter’s bin folder and typing:

    flutter --version

    You should see a message such as this:

    Flutter 3.3.9 • channel stable • https://github.com/flutter/flutter.git
Framework • revision b8f7f1f986 (2 weeks ago) • 2022-11-23 06:43:51 +0900
Engine • revision 8f2221fbef
Tools • Dart 2.18.5 • DevTools 2.15.0

    This will tell you if the installation is possibly ready. If instead, you see a message that the command is not found, double-check that you have your path correct; that’s typically the most likely cause for that error.

    Now, why did I say ‘possibly’? Because Flutter itself can tell you if there are any other tools you’ll need by running this command:

    flutter doctor

    Here’s an example of what I saw when I ran it:

    This tells me I have some of the necessary tools installed, but not all:

    • Flutter itself, as well as all the tools that came with it
    • Android toolchain: I don’t have this one.
    • Chrome browser: You’ll need this for debugging web versions of your app.
    • Visual Studio: This is the full IDE from Microsoft; you’ll need it if you want to develop your app for Windows Desktop. You can use the free Community version. For that, go here and choose the free Community version.
    • Android Studio: I don’t have this one.
    • VS Code: This refers to Visual Studio Code, the free editor/IDE from Microsoft, which is not the same as Visual Studio. It’s a separate tool and neither is dependent on the other. Before you install it, read my notes below.

    Before installing anything else, you’ll want to decide what platforms you’ll be targeting. If you’re going to include Android in that list, you’ll need to download and install both the Android toolchain and Android Studio. In that case, you’ll be developing from within Android Studio.

    But if you’re not targeting Android, you do not need to install the Android toolchain or Android Studio. The official installation docs are a little vague on this point, so I tested it out myself. I was able to target Windows desktop and a browser without needing to install any of the Android tools.

    If you’re not targeting Android, then you’ll want to install VS Code to do your development from within. You can find it here.

    Building an App

    For this example, I’ll continue with Windows, and I’ll build a quick Windows desktop app.

    In a command shell, I’ll first create a folder in my c:\dev to hold my projects by typing these commands:

    cd c:\dev
md projects
cd projects

    I’m going to make a Flutter app called flutter_demo by typing the following. (Make sure you’re in the projects folder before typing this):

    flutter create flutter_demo

    Note that the name for your project must be in all lowercase letters, and it can contain underscores. So, for example, using uppercase letters results in an error:

    If I type this:

    flutter create FlutterDemo

    I see this:

    "FlutterDemo" is not a valid Dart package name.
See https://dart.dev/tools/pub/pubspec#name for more information.

    When done correctly, you’ll see output such as this:

    Creating project flutter_demo...
Running "flutter pub get" in flutter_demo... 1,186ms
Wrote 127 files.
All done!
In order to run your application, type:
$ cd flutter_demo
$ flutter run
Your application code is in flutter_demo\lib\main.dart.

    Before we open the code, let’s run it! First, go into the new folder flutter created:

    cd flutter_demo

    Then run it by typing:

    flutter run

    This command runs whatever Flutter application is in the current folder. In this case, that’s the app you just created.

    When you start it, it will ask for some choices. Because I don’t have Android or an emulator installed, I only see options for Windows Desktop and Chrome and Edge. (Edge is based on Chrome, so it works, as well.) Here’s what I see:

    Multiple devices found:
Windows (desktop) • windows • windows-x64 • Microsoft Windows [Version 10.0.19044.2130]
Chrome (web) • chrome • web-javascript • Google Chrome 107.0.5304.107
Edge (web) • edge • web-javascript • Microsoft Edge 106.0.1370.37
[1]: Windows (windows)
[2]: Chrome (chrome)
[3]: Edge (edge)
Please choose one (To quit, press "q/Q"):

    Press the option for Windows. This will build the Windows desktop version (which might take a minute or so) and launch it, resulting in a window that looks like this:

    This isn’t much, but there’s a sample in it where you can click the plus sign and see the number in the middle increment. That’s all.

    Now let’s try running the same app in Chrome. First, close the app window and press Arrow-Up or re-type:

    flutter run

    This time, choose the option for Chrome.

    Now Flutter builds a web-ready version that runs on Chrome, starts a local web server to host the app, launches Chrome and pushes a URL to Chrome to load the app from the local web server. Here’s the browser window:

    Notice that it looks virtually identical to the desktop version but is inside a browser this time.

    If you’re a web developer, I encourage you to right-click inside the browser app and select View Page Source. Notice there’s a line that loads a file called flutter.js, and there’s some JavaScript code that responds to the window’s Load event that calls into Flutter. You won’t be writing JavaScript code, but it’s always good to have at least some understanding of what your front end is doing!

    Adding to the Code

    Now let’s add just a bit to the sample code. For this, I’ll use VS Code. From within the app’s main folder (in my case, c:\dev\projects\flutter_demo) type

    code .

    (Make sure to include the dot after the word code; otherwise, VS Code will open in whatever folder it last ran.)

    Before delving into the code, you’ll want to install a special Flutter extension for VS Code. Click the gear in the lower left and click Extensions. In the box labeled Search Extensions in Marketplace, type flutter. (Don’t click Enter; just pause a moment and the search will begin.) Find the one called Flutter that has over five million downloads, as shown here:

    Click the Install button. The button will show “installing” while the extension is being downloaded and installed.

    After the extension is installed, VS Code will ask whether you want to use it with your current project. You might also see a message regarding updating the Dart extension, which came alongside Flutter. Click Yes for the Flutter one; click Get packages for the Dart one. (You can ignore the message about opening the settings file.)

    Now you have all several flutter tools available VS Code’s Extensions Palette. Press Ctrl+Shift+P to open the palette. Type flutter and you’ll see the full list.

    For now, however, let’s first just run the app. Click the Run menu, and then click Run Without Debugging. You’ll see the Windows app open again.

    Now go back to VS Code. Even if you’re not familiar with Dart, if you know other “curly bracket” languages such as C++, C#, Java, JavaScript and so on, you’ll probably be able to read the code. There’s a function called main() that starts the app, providing a class called MyApp. That class is farther down in the code. Look closely at all the comments. Read them carefully and learn from them. The MyApp class contains a build function that returns an object with a “home” member; that member is an instance of MyHomePage, which is also a class in this file. Continue studying that code, and you’ll see mentions of widgets and layouts. Look closely at the function called _incrementCounter and how it’s triggered later on through an onPressed event.

    Conclusion

    Play around with the code; try changing some of the string literals, for example, until you’re quite familiar with it. Then dive into the first demo provided by the Flutter folks at Google, which you can find here. Soon you’ll be up and running with your own Flutter app that you can run on any device!

  • AWS re:Invent — Top 4 Things We Learned This Week

    AWS re:Invent — Top 4 Things We Learned This Week

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

    This week, four things that caught my eye from Amazon Web Services’ re:Invent 2022 conference: SnapStart turbocharges Lambda, Graviton3E ARM HPC SoC, AWS continues hiring, and AWS’s origin story. (more…)

  • GraphQL Vulnerability Analysis: The Top Threats

    GraphQL Vulnerability Analysis: The Top Threats

    Publicly available vulnerability data can be a goldmine for insights into how DevOps and DevSecOps teams can prioritize threats and improve security across the pipeline. With this in mind, Inigo recently performed a deep-dive analysis of known vulnerabilities affecting GraphQL components—including GraphQL clients such as Relay and GraphQL servers such as Apollo, Graphene, Ariadne, GitLab Enterprise, Magento and others. Our main data sources for this investigation were the MITRE CVE database and the HackerOne Hacktivity portal.

    Analysis and Findings From the MITRE CVE Database

    First, a few caveats about the MITRE CVE database. While it’s considered the source of truth for CVEs and the best data source available for understanding these vulnerabilities, it has its limits. Not every vulnerability gets reported, and not every reported vulnerability gets an assigned CVE identifier. Vulnerabilities generally receive a CVE identifier when an impacted software vendor or researcher recognizes a vulnerability and files a CVE request with MITRE. Large software vendors including GitLab, GitHub, Adobe and many more also serve as CVE Numbering Authority (CNA) partners, authorizing them to issue CVE identifiers themselves (often only for the scope of their own software). All this is to say that the MITRE CVE database is a strong data source for our analysis, but it shouldn’t be considered comprehensive.

    Inigo started its investigation by searching the MITRA CVE database for the term “GraphQL,” revealing 45 CVE records (at the time of the research) relevant to GraphQL clients, servers, and other components. Interestingly, the first tracked GraphQL vulnerability was CVE-2019-1000011 from 2019: Most likely not the first vulnerability ever discovered in GraphQL software, but the oldest available in this database.

    Researchers were curious to know which classes of GraphQL vulnerabilities were most common, and which GraphQL software has the most known CVEs. The following chart displays the results of the analysis answering the first question.

    Authorization bypass vulnerabilities are far and away the most common vulnerability class, and a majority representing 54.8% of all GraphQL vulnerabilities. At 16.7%, denial-of-service (DoS) vulnerabilities stand out as the second most common vulnerability class, followed by information disclosure (9.5%), code execution (7.1%), cross-site request forgery (CSRF) (7.1%) and injection (4.8%).

    Analysis into which GraphQL software has the most CVEs revealed the following:

    To be clear, these findings don’t necessarily speak to how hardened or how safe a particular GraphQL component is. Popular GraphQL servers simply draw more attention and have more eyeballs searching for vulnerabilities, whether they belong to attackers or security personnel. While this fact skews these results, viewing this data at a glance remains interesting.

    Analysis and Findings From the HackerOne Vulnerability Database

    The HackerOne Hacktivity portal offers a robust database resource that collects information on vulnerabilities as reported by researchers. The analysis looked at public reports of GraphQL vulnerabilities, finding 74 results since 2018.

    As the graph shows, identified GraphQL vulnerabilities fell mostly into the authorization class (87%), with DoS (7%) a far second and race condition and session management vulnerabilities each coming in at 2.8%.

    Bug bounties offer an interesting and likely influential factor here. Over the 2018-2022 timeframe, bug bounties granted for these vulnerabilities ranged from $250 to more than $20,000. At the same time, authorization vulnerabilities carry a high risk to sensitive data such as personally identifiable information (PII). This drives organizations to place premium bounties on these authorization flaws and motivates security researchers to focus on earning those prizes. Therefore, white-hat hackers will naturally test for authorization flaws first, perhaps leading to their overrepresentation in the data. It’s also important to note that bug bounty programs tend to prohibit testing for DoS vulnerabilities for obvious reasons, possibly reducing their representation here.

    Open-Eyed GraphQL Security

    For developers, DevOps and security teams tasked with safeguarding GraphQL deployments, the first step is knowing what you’re up against. The findings above should serve as an eye-opener that helps teams to prioritize threats, whether they be authorization, DoS and other classes of GraphQL vulnerabilities. As more and more organizations rush into GraphQL (increasingly migrating from REST APIs), security cannot be put on the back burner. There’s too much at stake, and ensuring the security of GraphQL deployments isn’t nearly as difficult or time-consuming as many teams currently think.

  • Key Findings From the 2022 State of GraphQL Report

    Key Findings From the 2022 State of GraphQL Report

    GraphQL, the open source query language, has been steadily growing in popularity over the past few years. The language is excellent for frontend development, as it creates a usable interface to fetch precisely the data required for the specific client at hand. You can also use it to aggregate multiple backend services and data sources.

    Studies show that the ecosystem around GraphQL is maturing—it has a very global user base and a growing number of tools exist to aid in its adoption. The 2022 State of GraphQL Report found that 61.8% of developers are happy with the overall state of the ecosystem. Yet many native GraphQL features go unused by developers, which suggests there is a wide range of experience levels, from novice to advanced users, working with the technology. This indicates there is plenty of room for growth and knowledge sharing.

    Below, I’ll review the key takeaways from the 2022 State of GraphQL Report, considering overall usage data and focusing on the popularity of specific features. We’ll also highlight the state of standard tools used in conjunction with GraphQL to get the job done.

    Analyzing Overall Usage Statistics

    First off, there is a wide variance in the types of GraphQL APIs in production today, ranging from private to public endpoints. The report found 47.9% of developers use GraphQL for exposing an API intended for a personal website or app, 40.4% use it for private unexposed APIs for internal usage and 19.5% use GraphQL for publicly available APIs intended for third-party developer consumption. This demonstrates its flexibility to cater to multiple scenarios. And while the majority of clients that connect to GraphQL APIs include browsers (62.3%), it’s commonly consumed by other client types such as native mobile apps, other servers and desktop apps.

    Previously, we discussed using GraphQL as a composition layer to combine underlying APIs and services. And the report backs up this idea that developers commonly use it to aggregate various data sources: 55.4% of GraphQL APIs hit databases, while 35% consume REST APIs and 14.6% eat other GraphQL endpoints.

    In terms of benefits, one strong point is the ability to enforce and validate types for every object in the API. Users find other top benefits to be avoiding overfetching and aggregating requests. Yet, some hurdles still present themselves. These top drawbacks include error handling, performance issues, client-side caching and security woes.

    Regarding user base statistics, most users have been working with GraphQL for less than five years. If we look at the type of sector utilizing GraphQL, we see it primarily leveraged in the programming and technology sector. This is followed by e-commerce and retail (16.4%), finance (8.9%) and news, media and blogging (7.2%).

    Many Advanced Features Go Unused

    Many of the more advanced GraphQL features still go unnoticed by the majority of users. For example, live queries is a feature that helps obtain live data from a GraphQL server, yet only 25% who know about it have used it. Over half of respondents had never heard of @skip, a directive that skips a field based on a value passed to it. Similarly, other directives like @specifiedBy, @defer and @stream also share little-to-no awareness or use.

    Analyzing feature usage becomes a bit more serious if we consider the unadopted security and performance features. For example, only 43.2% of respondents have disabled query introspection. Disabling query introspection is a suggested security best practice to limit a hacker’s ability to perform surveillance. But as we’ve previously covered, security by obscurity isn’t enough to protect GraphQL, and an additional security emphasis is often needed.

    As most GraphQL APIs are intended for personal or private scenarios, you would think that more security features would be leveraged to limit the threat of introspection and denial-of-service attacks. Yet, the report discovered low usage and awareness of security and performance features like query timeouts, query rate limiting and query cost analysis, all of which could be turned on to curb malicious behaviors.

    Tools Used In Conjunction With GraphQL

    Developers often seek to combine, aggregate or merge GraphQL schemas from different APIs. To do so, Apollo Federation is the most common solution, used by 22.5% of respondents. This is followed by Schema Stitching (16.9%), GraphQL Modules (4.4%), and GraphQL Mesh (2.9%).

    Looking at other technologies used in connection, Next.js is the most popular framework and PostgreSQL is the most common database used. TypeScript and JavaScript comprise the most common languages used to write a GraphQL backend. Developers also use a balanced mix of IDEs to query and test endpoints, including GraphiQL, GraphQL Playground, Postman, Apollo Studio, and Insomnia.

    The report also found relatively high usage and retention for tools like the GraphQL Code Generator schema builder, Apollo Client and Apollo Server. The data shows a crowded solution market with Apollo as an industry-leading outlier—many other clients, servers, API generators and schema builders have medium-to-high retention rates yet experience far less use.

    Final Thoughts

    The 2022 State of GraphQL Report sheds some interesting light on the state of GraphQL, validating a lot of the interest and trends we’ve covered lately on the blog. Of course, there is more to be said about many areas, such as smoothing the transition to GraphQL.

    One key finding is the low number of security features being leveraged by developers. A greater emphasis on API security is required to avoid incidents and retain a zero-trust approach. This emphasis is part and parcel of responding to ongoing software supply chain threats and will require more awareness and thought leadership around GraphQL security best practices.

    The 2022 State of GraphQL survey ran from June 15, 2022, to July 15, 2022, and collected 3,094 responses. The above analysis only scratched the surface and there are many other insights. For more findings, you can read the full results here.

  • GitLab Unfurls Dedicated SaaS Edition in the Cloud

    GitLab Unfurls Dedicated SaaS Edition in the Cloud

    GitLab today made available to a limited number of customers a single-tenant version of the software-as-a-service (SaaS) edition of its continuous integration/continuous delivery (CI/CD) platform.

    David DeSanto, vice president of product at GitLab, said the GitLab Dedicated option provides all the benefits of a cloud platform without running afoul of any potential compliance issues.

    Designed to be deployed on a cloud platform selected by the customer, DeSanto said the single-tenant edition of the platform makes sure that all the data stored in the cloud is isolated. In addition, the access to GitLab Dedicated is provided via a private network connection, he added.

    Initially, GitLab Dedicated is being made available on the Amazon Web Services (AWS) cloud with support for other cloud platforms planned for 2023 once it becomes generally available.

    GitLab is, in effect, trying to strike a balance between a lower-cost multitenant edition of the platform or, alternatively, requiring organizations to deploy an on-premises edition of the platform themselves, DeSanto said.

    In general, GitLab expects this latest version of the platform to appeal most to organizations that operate in highly regulated industries. However, the number of organizations looking to isolate their data in a private cloud to better protect their software supply chains is expanding, he noted.

    In the wake of a series of high-profile breaches and vulnerability disclosures, the number of organizations that are reviewing their software supply chains has increased. Less clear is the degree to which organizations will look to lock down their existing CI/CD platform versus replacing it with a more secure modern alternative that can be more easily accessed via the cloud.

    The challenge, of course, is replacing a CI/CD environment is not trivial, so organizations will need to consider the time and effort made over the years to customize their CI/CD environment. In some instances, that customization provides a meaningful competitive advantage. In other cases, however, the weight of maintaining all those customizations has become more troublesome than it’s worth.

    Each individual organization will need to decide to what degree they will want to manage the DevOps platforms used to construct applications. More organizations are deciding they prefer to devote as much of their resources as possible to writing code instead of managing the underlying CI/CD platform used to create their applications, said DeSanto.

    Regardless of approach, the number of organizations adopting DevOps best practices to build and deploy applications faster continues to increase. A CI/CD platform accessed via the cloud lowers the barrier to entry for smaller organizations that typically don’t have the skills and resources required to manage DevOps platforms.

    In the meantime, SaaS-based approaches should significantly increase the number of applications being constructed using DevOps workflows. The level of DevOps adoption will naturally vary by organization. However, the total number of custom applications being used to drive, for example, digital business transformation initiatives should considerably expand in the months and years ahead as more applications are built and deployed at incredible speed.

  • VMware Brings Java 17 Support to Spring Boot Framework

    VMware Brings Java 17 Support to Spring Boot Framework

    VMware this week made a Spring Boot 3.0 update for building microservices-based Java applications that is based on the latest long-term support release for the Java Standard Edition (SE) platform.

    Michael Minella, senior director of software engineering at VMware, said the latest edition of the framework supports Java 17. The hope is that adding this support will encourage organizations to move from Java 8 to the latest long-term release of the platform without requiring multiple upgrades to other previously released editions of Java SE.

    In addition, Spring Boot 3.0 now also natively supports a high-performance Java development kit (JDK) known as GraalVM along with version 6.0 of the Spring framework for building Java applications using OpenJDK, an open source version of Java SE that VMware made available earlier this month.

    VMware added support for Micrometer and Micrometer Tracing to improve the observability of Spring applications that will increasingly include multiple microservices dependencies.

    Finally, VMware also added support for Jakarta Enterprise Edition (EE) 10, an open source extension of Java SE that is being advanced under the auspices of the Eclipse Foundation.

    Minella said support for Java 17 coupled with GraalVM provides a stable foundation for building Java applications that are significantly faster than applications that rely on Java 8—still the most widely used edition of the platform. DevOps teams should begin to adopt a new standard for building and deploying the Java applications that still dominate enterprise IT environments, Minella said.

    There is, of course, no shortage of programming languages being used to build enterprise applications. After three decades, however, Java continues to dominate, in large part because of the sheer number of developers that have Java programming skills.

    It’s less clear how quickly legacy Java applications will be updated to run on Java 17 and the GraalVM. Now that Java 17 is supported in Spring Boot—the most widely used framework for building Java applications—the pace of adoption for the latest long-term release of the Java SE platform should accelerate in 2023.

    In addition, Minella noted the latest edition of the Spring framework will put organizations in a better position to take advantage of forthcoming advances such as Project Loom, an OpenJDK effort to replace threads with a lighter-weight concurrency model based on fibers that are managed via the Java runtime rather than the underlying operating system.

    Collectively, these and other technologies will make it less expensive to run Java applications that are significantly faster than previous generations of applications, he added.

    Most DevOps teams will find themselves managing a mix of Java applications—constructed using multiple variants of the core Java SE platform—for many years to come. However, it’s probable most new Java applications will be based on Java 17. In addition, there will be efforts to modernize legacy applications based on previous iterations of Java SE. As a result, most DevOps teams working in enterprise IT environments should expect to see an increase in the overall number of Java-based projects using microservices moving through their pipelines in the months ahead.

  • DevOps, Drought and Climate | Meta❤️PTP

    DevOps, Drought and Climate | Meta❤️PTP

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

    This week: Data centers cause climate change, and Meta is rolling out Precision Time Protocol. (more…)

  • Palo Alto Networks Buys Cider Security to Lock Down Pipelines

    Palo Alto Networks Buys Cider Security to Lock Down Pipelines

    Palo Alto Networks this week extended its efforts to secure application environments by agreeing to acquire Cider Security, a provider of a platform for securing continuous integration/continuous delivery (CI/CD) platforms, for approximately $195 million in cash.

    The acquisition of Cider Security, scheduled to close this quarter, will extend the reach of the company’s Prisma Cloud platform that was updated last year to include a set of tools for securing infrastructure-as-code (IaC) used to provision IT infrastructure. Palo Alto Networks previously acquired Bridgecrew, which had developed an open source Checkov policy-as-code tool. Last month, Palo Alto Networks added software composition analysis tools to Prisma Cloud, as well.

    Cider Security developed what it described as an operating system for application security. The solution creates a graph that enables DevOps teams to visualize the relationships between all elements that make up a software development environment, including code. It then makes it possible to apply a set of controls to remediate any vulnerabilities and attack paths that might be identified using any number of third-party scanning tools.

    Palo Alto Networks CEO Nikesh Arora told industry analysts the acquisition is an example of the company doubling down on securing software supply chains alongside its existing portfolio of platforms and services for securing production environments.

    It’s not yet clear who is in charge of DevOps platform security, but increasingly there will be some type of central security function that works with application development teams to lock down software supply chains, said Mike Rothman, general manager for Techstrong Research, an arm of the parent company of staging-devopsy.kinsta.cloud. “There’s going to be a central security group focused on securing the pipeline,” he said.

    As Palo Alto Networks continues to extend the reach of Prisma Cloud left, it continues to make a case for centralizing the management of cybersecurity through a portfolio of platforms that can be centrally managed via the cloud. It’s not clear how much organizations are centralizing management of security across their software supply chains and production environments, but Arora noted that interest in consolidating security vendors is high as organizations look to reduce the total cost of cybersecurity.

    In the meantime, organizations of all sizes are looking to employ DevSecOps best practices to better secure software supply chains in the wake of a series of recent high-profile breaches. In addition to scanning code for vulnerabilities, many of those organizations are starting to realize the tools and platforms used to build applications are also vulnerable to cyberattacks. The goal of those attacks is to insert malware that will manifest itself in any number of downstream applications that are eventually deployed in a production environment.

    It’s not yet apparent just how compromised those tools and platforms may be, but it’s clear software consumers are moving toward holding developers more accountable for vulnerabilities. The best-known example of those requirements is an executive order issued by the Biden administration that will require federal agencies to include software bills of materials (SBOMs) that list known vulnerabilities. Many enterprise IT organizations are expected to adopt similar requirements.

    One way or another, however, the tools and platforms that make up a software supply chain, along with the code they produce, are going to be subject to much greater scrutiny than ever before.

  • Data Centers IN SPAAACE | Discord GDPR Fine | AWS Fires Dead Wood

    Data Centers IN SPAAACE | Discord GDPR Fine | AWS Fires Dead Wood

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

    This week: The EU wants to put servers in orbit, a GDPR penalty for Discord, and Amazon has the hatchet out. (more…)

  • Infrastructure Abstraction Will Be Key to Managing Multi-Cloud

    Infrastructure Abstraction Will Be Key to Managing Multi-Cloud

    There’s no doubt we’re now living in a hybrid multi-cloud age. Companies are using major cloud providers like AWS, Azure and GCP with niche cloud computing providers emerging within the market. Simultaneously, many organizations still retain workloads in on-premises data centers or embrace colocation. Regardless of deployment pattern, DevOps teams desire the same elasticity as the cloud, but it’s becoming increasingly difficult to consistently manage the nuances of each service provider.

    To support today’s distributed polyglot architectures, a common layer could ease issues when deploying applications and provisioning various servers. By decoupling the infrastructure control plane from specific cloud providers, a unified management console could bring visibility into cost and performance, empowering CloudOps with knowledge before they commit. But engineering such an outcome would rely on plugins for each environment and a robust set of APIs to enable programmatic control.

    I recently met with Jake Warner, Cycle.io, to explore how increased infrastructure abstraction can solve the above problems. According to Warner, a standard layer for computing management is needed to enable consistent control over multi-cloud and bespoke on-premise environments. Below, we’ll define this concept and consider the benefits infrastructure abstraction could bring to modern enterprise software development.

    The Problems Facing Infrastructure Management

    We like to think that the cloud is pervasive and that everyone’s on board with a similar computing style. However, this is far from the truth. Multi-cloud is rising, and 95% of businesses are making multi-cloud a strategic priority in 2022, a Valtix study found. Yet only about half of respondents felt they had the appropriate tools and skills required to execute a multi-cloud strategy.

    “There’s a lot of value in multi-cloud, including reducing risk, ensuring better uptime and the flexibility to select the best hardware for the use case,” said Warner. “But multi-cloud is extremely complex.” Using multiple clouds means supporting increasingly variable operational processes for each environment. Whether it’s AWS, GCP, Azure, Equinix or Vultr, operators also require a deep level of visibility into telemetry data. This becomes complicated to track as software is increasingly modular and distributed across multiple computing regions.

    Furthermore, on-premises data centers are far from dead—surprisingly, a Spiceworks study found that 98% of enterprises still used on-premises servers. Traditional servers are often preferred due to corporate restrictions or to meet security compliance mandates. It could also be a cultural case of “if it works, don’t fix it.” The dilemma is that you can’t easily obtain common cloud features like auto-scaling and load balancing while on your own infrastructure.

    Another issue Warner described is that traditional platform-as-a-service (PaaS) companies present inherent limitations if you aim to build substantive applications and services. “Many of these PaaS offerings make it really easy to get started but, more often than not, developers are quickly forced to make compromises with their approach. These compromises can create long-term technical issues, especially when it’s time to scale,” he said. “Need a server with a specific hardware configuration in a targeted region? Good luck. For most PaaS companies, their exit ramp is just as defined as their on-ramp.”

    Movements Toward Infrastructure Abstraction

    We’re already seeing movement within the market to manage the operational burdens of multi-cloud. One example is the Infrastructure Abstraction Layer (IAL), open sourced by Cycle.io, which Warner explained can act as a standardized system for deployments. With the specification, an infrastructure provider can generate an API endpoint to enable the provisioning of infrastructure without requiring a deep integration between both services. With this endpoint live, an application development platform or orchestrator gains the ability to send standardized JSON payloads to provision servers, allocate IPs, configure regions and a number of other requests. The response, another JSON payload, confirms that the desired request has been completed and includes a unique ID.

    With more programmatic control over infrastructure, an engineer could interface with a standardized list of all the servers, across a number of providers, to deploy to and act upon this information in one unified console. This layer is an opportune location to help compare costs and server configurations for different regions too. It’s also an advantageous spot to filter by proximity to showcase the closest available servers to optimize delivery.

    Benefits of Unifying Multi-Cloud Deployment

    Decoupling the infrastructure management layer from service providers can bring potential benefits to DevOps, said Warner. For one, it enables operators to extend infrastructure automation into their private data centers, helping them achieve the same programmability they would have in the cloud. A degree of standardization can remove many of the cons of multi-cloud, too—”Developers can move from one provider to another provider without any major changes along the way,” he said.

    Of course, IT doesn’t want an added burden. This is why an API-based solution is required to enable programmability, said Warner. By taking a RESTful API approach to managing a hybrid infrastructure, operators could create custom flows based on fine-grained environmental characteristics that change over time, like latency, expense or location. “One of the neat things is it allows infrastructure providers to constantly make tweaks and improvements without having to resubmit their integration with an underlying platform,” said Warner.

    The Flexibility of LowOps

    Today’s software deployment is increasingly wide and varied—a recent HashiCorp report found that 76% of organizations are already multi-cloud. Multi-cloud brings many advantages, yet it also multiplies the number of operational tasks required. At the same time, organizations want to leverage investments into on-premises data centers for as long as they are economically viable. Automating DevOps for such a varied infrastructure can be difficult without a unified layer decoupled from each niche computing area.

    According to Warner, companies require a LowOps platform and the flexibility to abstract this automation on their own infrastructure when appropriate, which can vary widely. For example, operators may be working with a fleet of tens of thousands of IoT devices. Furthermore, as we’ve covered previously, a LowOps method can be beneficial to small-to-medium-sized companies that may lack the resources to support complex infrastructure like Kubernetes.

    Could something like IAL ever become an open standard? Well, at the time of writing, the IAL specification has only been implemented by Cycle.io and a few of its infrastructure partners, but there’s no reason it couldn’t be extrapolated into a common specification down the line, said Warner. He even foresees a community marketplace or shared registry for infrastructure abstractions, enabling platforms to support hundreds of cloud providers.

    In conclusion, the need for LowOps, combined with the rise of multi-cloud and the staying power of on-premises data centers, is fueling a requirement for a decoupled management center. Infrastructure abstraction could enable the convenience of a PaaS while empowering operators with custom infrastructure choices.