devopsy.kinsta.cloud

Tag: edge computing

  • Netlify Extends JAMstack Reach to Edge Computing

    Netlify Extends JAMstack Reach to Edge Computing

    Netlify, at its JAMSTACK CONF VIRTUAL event today, announced Netlify Edge Handlers, which make it possible to extend a Git-based workflow to edge computing applications.

    Company CEO Matt Biilmann said Netlify Edge Handlers, available in beta, puts the primitives in place for deploying serverless web applications based on a JAMstack software architecture that employs JavaScript, application programming interfaces (APIs) and markup languages, otherwise known as JAM, to isolate front- and back-end components of an application.

    A Git-based approach will also enable DevOps teams to extend workflows to edge computing applications that can be deployed on any number of platforms, he said. As an extension of a Netlify platform written in a modern Rust programming language, Netlify Edge Handlers makes it possible to build and launch web applications and websites based on a JAMstack architecture from within a continuous integration/continuous delivery (CI/CD) environment.

    Prior to the availability of Netlify Edge Handlers, building and deploying web applications on edge computing platforms required extensive coordination across teams, the creation of detailed edge logic with many dependencies and deviation from standard web development best practices, Biilmann said. Now, developers can write simple JavaScript that builds and deploys to the network edge in a way that enables simplified A/B testing, custom authentication and API aggregation, he noted.

    Developers also can build and manage edge logic from preview to production, including deploying those applications via the existing Netlify multi-cloud network.

    More application code is being pushed out to the edge because many organizations are now processing and analyzing data closer to where it is created and consumed, as part of their digital business transformation initiatives. Web applications that execute closest on a node to the user eliminate or reduce roundtrip request and response flows with the client.

    Biilmann also noted that because those applications are employing a platform developed using Rust, they are also inherently more secure.

    There may come a day when there are more application workloads collectively running at the edge than there are on cloud computing platforms. However, if that goal is ever to be achieved, it needs to become easier for developers to build those applications. Given the fact those applications are also likely to be targeted by cybercriminals, it’s critical to ensure those applications are as secure as possible.

    In the wake of the economic downturn brought on by the COVID-19 pandemic, many organizations have accelerated digital business transformation initiatives, many of which depend on edge computing platforms. The only way to achieve that goal, however, is to make it possible to build these applications using JavaScript tools that most developers of web applications have already mastered. Otherwise, organizations will need to invest in training developers to master another framework for deploying edge computing applications. That would require time they might not have.

    Regardless of the path forward, a massive wave of edge computing applications soon will stretch the boundaries and limitations of whatever DevOps processes organizations have in place today.

  • NVIDIA to Create AI Powerhouse by Acquiring Arm for $40B

    NVIDIA to Create AI Powerhouse by Acquiring Arm for $40B

    NVIDIA has announced its intention to acquire Arm from SoftBank for $40 billion as part of an effort to create a juggernaut that will build processors optimized for artificial intelligence (AI) applications that span edge computing deployment to the cloud.

    Under the terms of the proposed deal, Arm will operate as a subsidiary of NVIDIA and will continue to headquartered in Cambridge, UK. NVIDIA will pay to SoftBank a total of $21.5 billion in NVIDIA common stock and $12 billion in cash, which includes $2 billion payable at signing. SoftBank will retain a 10% stake in NVIDIA.

    NVIDIA CEO Jensen Huang during a conference call also committed to licensing the software NVIDIA uses to make graphical processor units (GPUs) using the same licensing model Arm has employed to encourage manufacturing partners to create processors based on its designs. In theory, that approach could substantially lower the cost of GPUs once the deal closes.

    However, because of all the regulatory approvals required, Huang said NVIDIA could not commit to a timeframe for the close of the deal. Previously, Huang noted it took NVIDIA a year to close the acquisition of Mellanox, a provider of storage and networking infrastructure.

    In addition to providing processors that drive gaming and CAD/CAM applications, GPUs from NVIDIA are widely employed to train AI models more efficiently than x86 processors from Intel or AMD. Processors from Intel are used more often to run the inference engines for an AI model once it is deployed. With the acquisition of ARM, NVIDIA gains access to processor technology that is emerging as a rival architecture for deploying AI models on a wide range of server and mobile computing platforms. Currently, Arm is best known for providing processors for mobile computing devices such as smartphones, which eventually will also be infused with a wide variety of machine and deep learning algorithms.

    In the meantime, many organizations continue to struggle with implementing AI. It typically takes a team of data scientists six months or more to build an AI model. Once that model is built, it then needs to be incorporated into an application as part of a DevOps workflow. In the meantime, business assumptions may change, rendering the AI model irrelevant. That requires the data science team to build a new AI model. In addition, as new data sources become available, AI models need to be updated. Most organizations are just now defining the processes for building and deploying those models, otherwise known as machine learning operations (MLOps), using many of the principles that were first defined by DevOps teams.

    Once those MLOps processes are defined, of course, IT teams then need to meld MLOps and DevOps workflows to keep applications that are updated more frequently synchronized with the AI model on which those applications increasingly depend.

    At this point, it’s clear every application will incorporate some level of AI. However, the speed at which AI might become pervasive is not likely to be all that fast anytime soon.

  • Making the Move to Edge Computing? Consider This 

    Making the Move to Edge Computing? Consider This 

    Edge computing has exciting potential, but there are certain considerations to thrive in today’s competitive landscape

    Data is king, especially in the current era of the data-driven business, where a data mindset and analytical capabilities are significant factors in determining future success. With so much data to be mined and monetized, more companies are recognizing the competitive advantages of edge computing, which can also jump-start the journey to becoming an autonomous digital enterprise. That said, a variety of security and infrastructure challenges may prevent some IT professionals from making the move, according to a recent survey by Volterra and Propeller Insights.

    Distributed models such as edge computing have always been attractive because of their ability to minimize network latency issues with large data and put essential functions closer to the technology consumer. Now, they’re even more attractive with new compute and application architectures and so many new data sources—network-connected and internet of things (IoT) devices, social media, customer engagement systems, transactional systems and systems of record—dramatically expanding the volume of data and changing the nature of the data collected. Edge computing also helps solve the traditional issues of optimizing for network capacity and performance and addresses new areas such as the localized pre-processing of all data sources (telemetry, video, mobile, etc.).

    It’s no surprise, then, that 54% of the IT leaders surveyed said they prefer edge to the cloud for operators who need to control and analyze data for local use cases, and to avoid the latency that can occur when sending edge data to public cloud-based apps. By moving certain workloads to the edge of the network instead, devices spend less time on the cloud, react faster to local changes, and operate reliably–even in extended offline periods.

    Edge computing still has its challenges and difficulties to overcome. Among them are key concerns such as a lack of resources or time for long-term upkeep of application and infrastructure, and managing distributed clusters as siloed instances rather than a single resource.

    Taking IT to the Edge – Edge Computing, That Is

    Despite the roadblocks, the value of edge computing is clear. This is why many companies are including edge computing models in their business plan. However, the performance, control and governance challenges that come with distributed models of compute, applications and data should be considered carefully beforehand.

    Innovative, data-driven companies that want to stay on the cutting edge and are planning an edge migration should develop a plan and long-term vision for their mix of data center, cloud and edge resources that consider their current and future use cases. Partnerships will also prove useful. By leveraging multi-vendor, commercial off-the-shelf solutions, enterprises can be more successful yielding value from edge computing than they would with single-vendor niche products. An ecosystem of seamlessly integrated solutions will help companies harness data and translate information into insight and actions that can optimize assets.

    As today’s enterprises seek to become more data-driven and evolve into the autonomous digital enterprises of tomorrow, it’s important to think about edge use cases as part of an overall automation strategy. Companies should consider how edge applications and distributed architectures will support them from a capacity, monitoring, deployment and service management perspective.

    Finally, edge computing’s advantages also come with the risk of security vulnerabilities if they’re not addressed from the outset, since the “attack surface” of a company’s IT estate becomes much larger. Organizations must deploy a multi-layer security approach that aligns with their edge initiatives while factoring in service-level needs to ensure assets are adequately protected.

    Edge computing has exciting potential, and the enterprises that make strategic investments and take a holistic, outlook-driven, secure approach to migration will thrive in tomorrow’s competitive landscape and years into the future.

  • Fastly Facilitates Observability at the Edge

    Fastly Facilitates Observability at the Edge

    Fastly this week announced it is adding the ability to collect tracing, customizable logging data and both real-time and historical metrics from a serverless computing framework designed to be deployed on edge computing platforms.

    Company CTO Tyler McMullen said the goal is to make it easier for IT to bring observability within the context of a DevOps to an edge computing platform.

    The Compute@Edge serverless compute platform enables IT teams to employ functions to execute code on an edge computing platform versus having to install virtual machines or containers. Those edge computing platforms are connected to a content delivery network (CDN) managed by Fastly.

    McMullen said that approach provides a way to deploy microsecond applications at the edge while still attaining observability in keeping with best DevOps practices. Otherwise, edge computing platforms become yet another black box that provides IT teams with no visibility.

    DevOps teams can send real-time logs to 27 and counting supported endpoints. Default log fields are automatically exposed to better determine the root cause of any issue. DevOps teams can also capture custom event details.

    Metrics such as CPU and RAM utilization can also be surfaced either in real-time or on a historical basis. The Compute@Edge service also honors request tracing parameters by maintaining them when they enter and leave the Fastly platform. Developers can tag individual end user requests with unique identifiers that can be shared with third-party platforms such as Datadog.

    Currently available in beta, Compute@Edge makes it easier for IT teams to employ a serverless computing framework to drive event-driven applications at the edge, McMullen said. Latency issues that arise when applications attempt to access cloud services are pushing more organizations to deploy real-time applications at the network edge. Functions running on a local serverless computing platform enable IT teams to achieve that goal in a way that consumes the smallest amount of IT infrastructure possible, he added.

    With the rise of 5G networking services, it’s now only a matter of time before the number of platforms on which a DevOps team needs to deploy code expands significantly. Most DevOps teams are already challenged by all the unique platforms to which need to deliver code. Edge computing could potentially exacerbate those issues because each edge computing platform tends to have unique attributes. A common serverless computing framework running on each of those edge computing platforms could help streamline continuous delivery.

    Of course, it’s too early to say what impact the downturn on the economy will have on edge computing projects. In theory, at least, organizations are gearing up to deploy these applications in anticipation of wireless 5G connectivity services being widely available and affordable. Chances are high, however, with more organizations not willing to send people to install applications on those endpoints manually, reliance on DevOps processes and CDNs to automate application delivery at the edge will become a requirement.

  • JFrog Extends Reach and Scope of CI/CD Platform

    JFrog Extends Reach and Scope of CI/CD Platform

    At its online JFrog swampUP Conference today, JFrog announced it has extended the reach of its ability to distribute software to include options based on peer-to-peer and content delivery network (CDN) mechanisms.

    In addition, JFrog expanded the reach of the JFrog Pipelines continuous integration/continuous delivery (CI/CD) platform, enabling DevOps teams to build their own library of reusable pipeline steps via an Extensions Development Kit (EDK). DevOps teams can encapsulate frequent and common actions in their pipelines that can run sequentially or in parallel. That approach also serves to reduce the need to rely on plugin modules to extend a JFrog delivery pipeline.

    Finally, JFrog has added another free public artifact center that provides a means to manage Helm charts, which are widely employed to deploy applications on Kubernetes clusters. ChartCenter is intended to make it easier to deploy microservices based on containers.

    JFrog CEO Shlomi Ben Haim said all three additions to the JFrog portfolio extends the ability for users to manage the entire DevOps workflow from integration to delivery regardless of what type of software is being deployed or where it is installed.

    As DevOps teams look to deploy software on edge computing platforms within an internet of things (IoT) environment, Ben Haim said they will need to be able to employ either a peer-to-peer or CDN-based approach to manage that process efficiently. Existing mechanisms are not designed to handle large volumes of artifacts that need to be delivered in a specific order. The new mechanism added to the JFrog CI/CD platform enables DevOps teams to achieve that goal without having to acquire a separate platform, he said.

    In fact, Ben Haim noted, efficiently delivering software to edge computing platforms represents the next great leap forward for DevOps. Achieving that goal, however, will only be practical if the entire CI/CD workflow process keeps track of all the dependencies and metadata end-to-end, he said, noting that approach will enable endpoints to pull only the delta code required to update the software after an application is initially deployed.

    There is no doubt extending best DevOps practices to edge computing platforms will be a major challenge. Most DevOps teams already struggle with CD because each platform software is being deployed on is unique. Because of a general lack of standardization in terms of potential endpoints that might be deployed at the edge, that “snowflake” issue is likely to become even more exacerbated as IT environments become more distributed than ever.

    In general, Ben Haim said far too much of the DevOps focus continues to be on source code management when in reality the biggest issue IT organizations face is how to efficiently manage binaries. At a time when organizations are making massive investments in digital business transformation, Ben Haim noted the rate at which software is deployed and updated is about to accelerate dramatically.

    As such, Ben Haim said it’s now only a matter of time before DevOps workflow processes will need to be able to scale well beyond their current limits.

  • Why the Success of Edge Computing Relies on a Linux Legacy

    Why the Success of Edge Computing Relies on a Linux Legacy

    At this point you’ve certainly heard rumblings of the promises of edge computing and may wonder if it’s right for your organization and how to assess its viability. The way we think about edge is as a decentralized extension, or evolution, of cloud computing, enabling many of the same technologies and applications to be leveraged in areas/locations that weren’t possible before.

    I believe that the promise of edge computing and the opportunity it unlocks is valuable enough to be a major driver in our industry over the next decade. Here’s how to think about implementing edge computing in your organization. 

    Getting Started

    Since edge is an evolving space, the exploration of edge computing should start as soon as possible, and we’d recommend a phased implementation approach to help deal with change as it comes. 

    Many of the companies we work with who delayed their cloud initiatives found that it contributed to their falling behind from a technology standpoint. Given the choice, it’s better to deal with some sharp edges — no pun intended — than to fall behind your competitors in reaping the benefits.

    Edge requires careful life cycle analysis at the beginning of the journey, rather than an afterthought. The decentralized nature of edge computing raises the stakes and amplifies any potential problems you would have in other computing scenarios. So as you begin, keep in mind issues such as adaptable infrastructure, security and life cycling between hardware and software.

    The Value of Adaptability, Linux and Open Source

    Twenty-five years ago, innovation was a slow, laborious, bug-filled crawl — with any advances crippled by proprietary technology. The breakthrough that paved the way for the continuous, rapid pace of innovation possible today was Linux.

    We need to heed the lessons from the early days around private cloud adoption and, more recently, Linux containers with regards to adaptability. Many man-hours were lost in slash-and-burn style rebuilding of infrastructures. The logistics at the edge make it impractical to have the same learn-as-we-go freedom we had inside the datacenter. 

    As we’re likely to see edge computing evolving quickly, the only adaptable architectures will be the ones that can avoid a total tear-down. Adaptable architectures will also be well-positioned to take advantage of the newer capabilities as they become available. 

    Remember, Linux has a strong history in the embedded world and is well adept at tackling a number of the historic challenges in this space. The more immediate impact is being felt at the distribution level. Our distributions, for example, have objectives around minimization and we expect to see more low-level enablement work on the security side for edge happening in the near future.

    For edge computing to reach its full potential, we need to be completely driven by open source and open standards. What we’ve learned from previous technology waves is that while most proprietary technologies have their merits, they miss out on the multipliers that can come from a thriving community.

    Final Considerations

    Security is a longer topic on it’s own, but given that we’re giving up many of the security barriers that are easy to take for granted in the datacenter and cloud (physical access, networking perimeter, security groups/policy, etc.), we are going to rely more and more on lower-level hardware and operating system security.

    No company wants to risk a common vulnerability across a hundred thousand nodes. This makes it our job to keep enterprise deployments from following the pattern of some consumer-grade devices that are long out of software maintenance.

    For edge computing innovation, we need to be thinking more about how we create sustainable solutions and technologies given how many deployments will require a longer life cycle and are more tightly bound to hardware and equipment refreshes. The path of innovation leads from Linux to and through the network edge. Companies that follow this approach will be better positioned to leverage the promise and power of the edge while avoiding fragmentation and lock-in.

  • How FaaS Is Disrupting Workflows: New CSP vs. CDN Services

    How FaaS Is Disrupting Workflows: New CSP vs. CDN Services

    Function as a Service (FaaS), the popular incarnation of serverless computing, along with containers, has played an important role in the migration from monolithic application architectures to those based on microservices. Its introduction has changed the way developers think about infrastructure and application development. While at the same time, it has also driven evolution in the consumption-based infrastructure models we saw introduced with the advent of elastic computing.

    FaaS has simplified broad adoption of value-add platform services from the major cloud service providers (CSPs) such as database and authentication services. It has quickly grown to become a viable infrastructure option for developers and IT professionals alike, serving as another tool in the chest – perfect for short-lived or ephemeral tasks. In recent months, we’ve seen announcements from content delivery network (CDN) providers touting a new breed of FaaS offerings promising low latency, workflow customization and cost containment. 

    CSP FaaS vs. CDN FaaS

    CSP FaaS resides in regional hyper scale data centers with the number of data centers in a region typically in the low single digits. These are the same data centers where the myriad of infrastructure and platform services are offered. Enterprises spin up their applications in virtual private clouds in a single region, sometimes they configure a backup region but even with today’s tools it is still complicated to manage data replication/consistency and ensure environments are kept in lockstep.

    In contrast to CSP FaaS, CDN FaaS solutions are highly distributed with various PoP locations. These CDN FaaS architectures are typically integrated with the providers’ edge delivery locations. Depending on vendor architecture, there could be hundreds of edge locations. Whereas CSP FaaS benefits from being collocated with platform services, CDN FaaS benefits from being closest to CDN action, where end-user requests/responses are received and processed. This is where edge computing comes into play because it minimizes latency while allowing for custom content delivery workflows.

    Empowering Innovation by Enabling Customization

    Developers use functions to customize content delivery workflows to create more compelling user experiences. Up to this point, CDNs provided limited capability for developers to define custom workflows via their own code. Flexibility has been limited to predefined “rewrite rules” and custom behaviors are the product of professional services-led engagements, which is not exactly developer friendly. CDN FaaS changed this, handing power to developers to deploy code and create unique, differentiated user experiences.

    The Make Or Break Element: Latency

    It is important to minimize latency between application services that rely on FaaS to avoid program timeouts. CSP FaaS options typically offer a broad range of event-triggers and run-times/programming languages to support developer preferences and align with the other elements of the development environment. 

    CDN FaaS has request triggers that are integrated with end-user or origin server request/response flows. FaaS invocations are typically a result of an end-user requesting content or an origin server providing a response that needs to be customized on a per end-user basis to reflect their preferences. The scale and latency expectations are so demanding that the run-time options are often limited to those that provide the lowest memory footprints and highest performance. CDN FaaS can also take advantage of the caching technologies further improving latency to complete functions – especially when remote service or network calls are involved. 

    How Do the Costs Stack Up?

    For CSP FaaS, the pricing model is two dimensional. It is based on the number of requests combined with the allocated memory and the elapsed time of function execution. Some of the CSPs are offering generous free tiers to entice customer adoption – and remember, Function as a Service drives adoption of many of the CSP’s higher value platform services.

    When it comes to CDN FaaS, the pricing models are similar, some organizations are charging for requests only but they limit memory foot and the time a given function is allowed to run. However, there is typically a premium to run FaaS in those highly distributed edge locations. Which is no surprise because cost models are higher for distributed/global build outs than centralized models. Also, due to the nature and demands of web and video services, request volumes are likely to be an order of magnitude higher than CSP FaaS requests. 

    Not All Faas Services Are Created Equal

    Function as a Service is an important part of our infrastructure as a service (IaaS) choice but it’s unlikely enterprises make a CSP solely on the FaaS offering. Typically, the decision is based on what value-add platform servers are available to build and support the application, and how seamless can those services be integrated with FaaS.

    For CSP FaaS, it is all about the bigger picture, the infrastructure and platform choices. This is also true with CDN FaaS because it is unlikely a CDN purchasing decision will be made on that CDN’s FaaS capabilities in isolation. The selection criteria will include FaaS but the larger weighting factors will include the content delivery capabilities, such as global reach, capacity, origin offload, feature support and so on.

    Overall, CSP FaaS are optimized for flexibility, multiple run-times, broad range of request triggers and tight coupling with CSPs’ higher-value platform services. Latency is important but the focus is within the CSP region or customer’s VPC and the use cases are often enterprise applications for B2B technology companies. Meanwhile CDN FaaS is all about performance, run-time efficiency and latency. It’s about running the functions in conjunction with the CDN – closest to where end-user requests originate and media responses are delivered. CDN FaaS requires enormous scale – on a global scale versus a single, centralized region.

  • Is Your Infrastructure Ready for Edge Computing?

    Is Your Infrastructure Ready for Edge Computing?

    Like many IT innovations, edge computing began with engineers as a natural extension of technology to address a growing need. The concept isn’t new; distributed computing has been around for decades. But, at the same time standards began to converge and edge hardware started making the rounds at trade shows, the hype machine saw an opportunity. It amplified edge’s considerable promise in reducing latency, offering software-defined deployment, decreasing cloud networking costs and more. But as is too often the case, the bold feature bullets ignored the production concerns businesses must address, including edge computing’s rough spots and the additional operations complexity it adds.

    Of course, edge computing will survive a little overexcited promotion, just like many of the once improbable technologies before it. People used to say, “What? Abstract all my data center applications away from the hardware as virtual servers? Impossible!” A decade later, we can’t imagine how we’d deliver traditional enterprise services, cloud computing, online retail, media streaming and everything else in between without exactly this. Virtualization survived its awkward hype adolescence, and edge computing will, too. The needs edge computing addresses are only growing.

    Thanks to engineers and operations teams, the edge distributed model is moving toward practical use. It’s proving itself capable of meeting requirements for new levels of network performance through reduced latency, scalability and, more importantly, manageability. For some businesses, it’s even reducing costs over the long haul.

    Not All Data Is Created Equal

    With the proliferation of connected devices and a growing focus on 5G-enabled technology, tech pros should set aside their natural reluctance to wade through the edge hype and consider it a genuine possibility. Its adoption is following the rise of emerging technologies and the applications taking best advantage of it: 5G, augmented reality, autonomous vehicles, IoT and smart manufacturing. These environments require not only low upstream latency, but high-performance compute and timely result data. Light only travels so fast, pushing infrastructure closer and closer to consumers for faster, more seamless processing in the form of brand-differentiating user experiences.

  • Chef Adds Support for Arm Graviton 2 Processors on AWS Cloud

    Chef Adds Support for Arm Graviton 2 Processors on AWS Cloud

    Chef announced this week that its offerings for managing and testing infrastructure as code now support Graviton 2 processors from Arm on the Amazon Web Services (AWS) cloud.

    AWS this week announced the availability of an M6g instance of processors on its public cloud. Based on a 64-bit Arm Neoverse N1 architecture, the M6g processors were jointly designed by Arm and Annapurna Labs, a unit of Amazon.

    According to AWS, during a preview program platforms such as Honeycomb consumed 30% fewer instances on M6g than the widely employed AWS C5 instances. Treasure Data, a provider of data analytics software, reported a 30% performance increase while seeing a 20% cost reduction compared to similarly sized M5 instances. The Amazon ElastiCache service team found that M6g instances deliver up to 50% throughput improvement over M5 instances on Redis.

    In addition, AWS this week revealed it also plans to add compute-optimized C6g instances and memory-optimized R6g instances based on 64-bit Arm processors.

    The Arm processors in the cloud are expected to provide a foundation for building hybrid internet of things (IoT) applications spanning AWS cloud services and instances of Arm processors that are widely employed in embedded systems. Previously, AWS launched an AWS Greengrass initiative through which it encourages developers to build and deploy cloud-enabled IoT applications on edge computing platforms.

    Vikram Ghosh, vice president of business development for Chef, said DevOps teams can now automate the provisioning of Arm processors using the same Chef tools they employ to provision instances on other types of processors running on the AWS cloud.

    It won’t be long before 64-bit instances of Arm processors start showing up on other cloud computing platforms, noted Ghosh. In fact, between the rise of Arm processors alongside graphical processor units (GPUs) the types of processors readily available in the cloud have never been more diverse, which Ghosh said is driving increased demand for tools to manage infrastructure as code.

    It’s still early days as far as adoption of best DevOps practices to build and deploy IoT applications is concerned. However, the highly distributed nature of IoT applications—which in many cases will need to be updated frequently—lend themselves to being managed more efficiently using DevOps processes. In most cases, these IoT applications represent “greenfield” applications where there is no legacy process in place that potentially would create a culture clash.

    Forecasting demand for edge computing applications in the wake of the COVID-19 pandemic is difficult. However, the general expectation remains that more application code will be moving closer to the point where it is being consumed, especially when 5G wireless networking services become more available. In fact, many of those applications are being built now in anticipation of those networking services being able to connect edge computing applications with backend cloud resources.

    Once those applications are built, the next big challenge will be finding a way to secure and continuously update them. In the meantime, however, the number of edge computing applications being built today in the cloud for edge computing platforms based on Arm processors is about to increase substantially.

  • IBM Looks to Drive Edge Computing

    IBM Looks to Drive Edge Computing

    IBM today at its Think Digital conference launched an edge computing initiative anchored around an IBM Edge Application Manager, through which a single administrator can manage up to 10,000 nodes.

    Hillery Hunter, vice president and CTO for IBM Cloud, said IBM Edge Application Manager is based on the Open Horizon open source software originally developed by IBM that is now under the auspices of LF Edge, an arm of The Linux Foundation focused on networking and edge computing platforms. Open Horizon makes uses of machine learning algorithms to automate the management of fleets of edge computing platforms.

    IBM also launched IBM Telco Network Cloud Manager to orchestrate both virtual and container network functions. IBM Telco Network Cloud Manager is built on top of an instance of Red Hat OpenShift, which is based on Kubernetes, and Red Hat OpenStack Platform.

    Finally, IBM is making available a range of edge-enabled applications, including IBM Visual Insights, IBM Production Optimization, IBM Connected Manufacturing, IBM Asset Optimization, IBM Maximo Worker Insights and IBM Visual Inspector.

    Like most IT vendors IBM sees the rise of application workloads on the edge as an opportunity to drive adoption of hybrid cloud computing. In the case of IBM, all of these offerings run on the Red Hat OpenShift platform.

    IBM also announced the IBM Edge Ecosystem, which brings together independent software vendors (ISVs) and IBM partners to craft edge computing solutions. Additionally, IBM launched the IBM Telco Network Cloud Ecosystem, which is more narrowly focused on edge computing platforms deployed for telco-focused environments such as a wireless 5G network.

    IT vendors participating in those initiatives with IBM include Cisco Systems, Dell Technologies, Juniper, Intel, NVIDIA, Samsung, Packet & Equinix, Hazelcast, Sysdig, Turbonomics, Portworx, Humio, Indra Minsait, EuroTech, Arrow, ADLINK, Acromove, Geniatech, SmartCone, CloudHedge, Altiostar, Metaswitch, F5 Networks and ADVA.

    Edge computing will undoubtedly force organizations to embrace DevOps more aggressively. Managing thousands of edge computing platforms will require not just higher levels of IT automation infused with machine learning algorithms, but IT teams will also need to be able to deploy, secure, update and manage applications distributed across thousands of endpoints.

    IBM, of course, is not the only IT vendor eyeing the edge computing opportunity. The challenge IT organizations will face first is building new classes of latency-sensitive applications running in near real-time that will be built mainly using microservices. Once those applications are built, organizations will then need to update them continuously within the context of a highly scalable IT management framework.

    Naturally, some organizations will prefer to rely on external IT service providers to rise to that challenge while others will continue to build and manage their own applications and infrastructure. Regardless of the approach, the level of scale and complexity at which IT is being applied is about to reach a level that once would have been unimaginable. Not only will more applications run in near real-time, those applications will be integrated and share data with batch-oriented applications running in the cloud and local data centers. The challenge is finding a way to automate the management of IT at scale without requiring organizations to rely on manual processes, for which there are simply not enough IT professionals available to manage.