devopsy.kinsta.cloud

Category: Infrastructure/Networking

  • Improving Mainframe Agility With DevOps

    Improving Mainframe Agility With DevOps

    Mainframe workloads were on the rise even before the coronavirus pandemic, and transaction-processing mainframes became vital as lockdowns went into effect and every aspect of business and personal life occurred online. Mainframes are reliable, secure, highly available and affordable, and it is essential for organizations to ensure their mainframe can achieve peak agility to enhance profitability and improve customer experience.

    There are four areas of focus for DevOps teams who want to improve mainframe agility: teamwork, cloud services, KPIs and automation. Let’s look more closely at each one.

    Encourage Teamwork Between DevOps and Mainframe Ops Teams to Improve Agility

    It’s vital that mainframe ops teams work seamlessly with DevOps teams to ensure adoption of best practices in both areas, where practical, and that those best practices are adhered to. No matter how skilled your DevOps team, they must always be open to learning from mainframe professionals, operational and cybersecurity experts.

    To truly empower everyone on your team to achieve maximum mainframe agility, mainframe code must translate within the larger, multi-platform DevOps toolchain. If DevOps and mainframe code are not in sync, mainframe code could slow down software development lifecycles. Important processes, such as diagnostics, test execution and source code need to be integrated to enable DevOps teams to achieve better productivity.

    Enterprise DevOps is shifting focus away from software development exclusively to encompass surrounding processes within organizations. Successful DevOps teams must be able to work with cybersecurity experts and mainframe ops teams throughout the coding life cycle to ensure that everyone is on the same page and applications are functioning optimally.

    Decide Whether to Move Entirely to the Mainframe or Integrate Cloud Services with On-Premises Mainframes

    Scaling your organization for growth by migrating entirely to the cloud is not necessarily the right choice for everyone. In some cases, moving away from the mainframe’s core systems can be costly and unnecessary.

    Cloud-based services don’t have to be eliminated entirely, either. The cloud can and should be used for business processes that could benefit from real-time data updates, easy team collaboration and seamless integration with other software and tools. Mainframes excel at functions that require reliable, secure transactions.

    Whatever decision your organization makes, it must be communicated and agreed to at all levels. A customer-centric approach is ideal here, where the needs of the business are considered, but a seamless customer experience is prioritized.

    Establish Measurable KPIs

    Achievable and measurable key performance indicators (KPIs) are essential to monitoring your progress as an organization. KPIs for mainframe functionality usually include an availability rate of 99.999%, which roughly translates to downtime of less than 5.6 seconds per year. KPIs also generally measure time windows for batch completions. Software delivery velocity, efficiency and quality should be evaluated, but make sure you’re not prioritizing one of these metrics at the expense of another.

    There are more nuanced goals that need to be prioritized, too. Continuous improvements in software delivery are harder to quantify, but no less important. By fostering a collaborative environment where communication is key and teamwork is valued, your organization can create a better product or deliver better services for developers and customers.

    Use Automation Whenever Possible for Mainframe Agility

    Automated testing and AI-enabled processes can solve problems in real-time and free your DevOps teams to focus on larger issues. Mainframe ops teams can save their organizations money by relying on automated processes, which can also reduce personnel costs.

    Despite the benefits of automation, mainframe code is often removed from automated processes commonly applied to DevOps toolchains. Javascript, for instance, is one of the most commonly used programming languages due to its platform independence. It’s an essential tool for DevOps developers to enable the smooth configuration and installation of applications.

    But as infrastructures grow more complicated and surface areas expand to accommodate more users, operations teams can feel overwhelmed. With the continuous pressure to create new and better software on accelerated timelines, DevOps teams can unwittingly introduce vulnerabilities in Javascript coding as they speed through the software development and delivery pipeline.

    Automated mainframe diagnostics and optimization tools are vital to improving both the customer and developer experience.  Comprehensive and accurate data presented to mainframe ops teams in real-time can detect vulnerabilities and to find and fix potential issues.

    Ultimately, the mainframe is here to stay, with 93% of software experts citing the strength, reliability and scalability of the platform. Mainframes form the backbone of most monetized applications and websites, so it’s no surprise that mainframe agility has become a top focus for many IT departments. No matter how sleek and flashy your application is, if customers have a bad experience at the transactional level of the process, it could mean lost sales.

  • Cloudflare Lays Out GitOps Ambitions for CDN Platform

    Cloudflare Lays Out GitOps Ambitions for CDN Platform

    Cloudflare’s acquisition of Linc is the latest move in the hosting provider’s move to better align its content delivery network (CDN) service with the tools and frameworks organizations rely on to build modern applications using GitOps processes, according to CEO Matthew Prince. Cloudflare also announced other updates and automation-related features, including a way to automatically deploy JavaScript applications using Linc’s technology.

    Prince said these latest moves are part of an ongoing effort to simplify integration of front-end applications with back-end services.

    Cloudflare Pages, for example, enables developers to select their preferred repository, identify what types of frameworks they are using, and then automatically deploy their applications on the Cloudflare CDN. The goal is to automate the continuous integration process in a way that enables developers to focus more of their time and effort on developing code, said Prince.

    Linc’s technology, meanwhile, will make back-end services more accessible to front-end applications using Front-end Application Bundles (FABs) that accelerate server-side rendering by combining front-end and back-end logic. The result is better performance across any type of application that relies on JavaScript, application programming interfaces (APIs) and markup languages, otherwise known as JAMstack, a framework for building complex applications.

    Prince said JAMstack adoption is accelerating because it allows developers to continuously modify the user experience (UX) without the need to modify back-end services. The CDN, meanwhile, has emerged as a platform for continuously deploying applications closer to the point where they are consumed by the end user, said Prince.

    That’s become especially critical at a time when digital business processes require data to be processed in near-time, and as closely as possible to the point where it is generated, said Prince. That’s not possible when application logic runs on a public cloud, Prince added.

    Cloudflare currently has points of presence in 200 cities worldwide, and is actively courting developers as part of an effort to usurp CDN rivals. Most recently, Cloudflare added a Durable Objects capability that makes it possible to run stateful applications across a distributed, serverless Cloudflare Workers service.

    Ultimately, Prince said the goal is to automate the majority of the DevOps process, as code moves from a Git repository to the network edge. A CDN will also provide the means to monitor and secure applications running at the network edge, Prince added.

    It’s not clear how much application logic will be pushed to the network edge via CDNs; however, it’s apparent CDNs are emerging as an important deployment platform that should be incorporated with DevOps processes. How providers achieve that goal is, in part, dictated by the framework used to build an application.

    Cloudflare’s moves are indicative of the larger trends of automating DevOps processes, a development that should make DevOps best practices more widely accessible to many more developers.

  • BMC Expands Scope of Mainframe Management Portfolio

    BMC Expands Scope of Mainframe Management Portfolio

    BMC this week updated its portfolio of mainframe tools as part of an effort to make mainframe platforms more accessible to IT operations teams and developers.

    At the core of these offerings is BMC Automated Mainframe Intelligence (AMI), which embeds machine learning algorithms in mainframe platforms to automate a wide range of processes. BMC AMI supplants the company’s existing MainView tools with a framework that promises to make artificial intelligence (AI) more accessible via a revamped user interface.

    BMC AI Ops

    John McKenny, senior vice president and general manager for ZSolutions at BMC, said an AI model based on the data collected by BMC AI can now be spun up in a matter of minutes, and can identify a potential issue days before it might otherwise occur.

    BMC AMI also exposes a REST application programming interface (API) through which more mainframe tasks will be automated.

    McKenny said as organizations accelerated digital business transformation initiatives in the last year, the need to modernize mainframe platforms became more acute. Mainframes are now the backend for multitier application environments that need to be managed in concert with other platforms, McKenny said.

    BMC is also adding Compuware zAdviser dashboards to the DevOps platform it gained with the acquisition of Compuware last year. BMC also updated Compuware Topaz for Total Test to streamline test creation for mainframe applications. There’s a growing need for better tools to test digital business processes created for the mainframe, noted McKenny.

    Other updates include Control-M job scheduler and Compuware ThruPut Manager integration, to ensure jobs run at or before their expected times on a mainframe, and an update to BMC AMI Data for IMS that simplifies database management in mainframe environments.

    Finally, BMC updated the BMC AMI Security offering with the Compuware Application Audit tool; this update allows for better capture of relevant user access and behavior data.

    McKenny said while mainframes remain one of the most secure platforms available, administrators must ensure security policies are properly implemented. IT organizations should avoid complacency and ensure zero-trust security in mainframe environments, McKenny said.

    McKenny added that, despite their long tenure and the rise of cloud computing, mainframes remain relevant. Many organizations determined that the fastest way to achieve their digital business transformation goals is by extending their mainframe platforms – platforms many of them already rely on to process and analyze transactions.

    What’s changing is the IT professionals that manage mainframes alongside other platforms, such as the cloud. Many of those IT professionals naturally expect integrated AI capabilities that enable the average IT administrator to manage a platform that was once the sole realm of dedicated IT specialists.

  • The Biggest Motivators and Barriers for SD-WAN Adoption in 2021

    The Biggest Motivators and Barriers for SD-WAN Adoption in 2021

    The SD-WAN market has exploded in 2020, driven by the need to support increasingly remote workforces, the emergence of the AI-driven WAN and the requirement to deliver branch performance that matches campus networks. As enterprises look at the year ahead, support for the distributed workforce remains a top priority, and SD-WAN is a crucial technology that businesses need to invest in to thrive in the “new normal.”

    As we head into 2021, these are the biggest motivators for the enterprise to adopt SD-WAN:

    • Increased demand for robust video quality: The days of in-person conferences and meetings have been traded with back-to-back Zoom calls. Though lags and connectivity issues are understandable, they can be frustrating and ultimately lead to decreased productivity. Experiencing these issues has increased the demand for more robust and higher bandwidth network connectivity, which is critical for video communications. This increasing demand is expected to continue to rise—although some businesses are planning to return to the office, many are adopting a hybrid work model that will require at last part-time remote work.
    • Boosting bandwidth without breaking the bank: Outside of video calls, the surge in remote work has increased pressure on overall network bandwidth. The solution for organizations is, of course, to add more bandwidth, but doing so can be expensive. SD-WAN is an attractive option for increased bandwidth pressure because it’s a solution that can meet bandwidth pressure demands while remaining cost-effective.
    • Centrally operated networks needed for distributed sites: Once enterprise video quality and bandwidth needs are fulfilled, the next step is to ensure that IT teams have the resources they need to effectively operate remote networks and deliver a great user experience from client to cloud. SD-WAN is a useful IT tool for network management because it provides full visibility into what’s happening across the network. And with the recent emergence of AI-driven WAN solutions, IT teams have more tools than ever before to get insight into user experience, enabling them to proactively and remotely resolve issues.

    Despite the many benefits of SD-WAN, there are still a number of barriers that are keeping enterprises from adopting this technology, including:

    • Concerns about quality of service (QoS) for applications across WAN: With SD-WAN solutions shifting traffic away from dedicated private circuits towards the public internet to reduce cost, businesses are often concerned about their ability to assure QoS for their critical applications. These businesses should look for solutions that provide insights into the experience from client to cloud as well as leverage data science and AI to detect anomalies. They should also automate the root cause determination and resolution through self-driving or IT actions.
    • Lack of insight into user experience: Many SD-WAN solutions lack the insight into both user and app experience from wireless to wired to WAN, whether due to the use of link-based VPN connections rather than session-based protection and/or the lack of rich streaming telemetry from the network devices to a modern cloud-based AI system. New AI-driven solutions and session-based technologies are now available that can improve this insight to simplify network operations and assure great user experiences from client to cloud.
    • Securing remote sites from potential security threats: By further extending the threat surfaces with a more distributed workforce, many organizations are concerned about the potential security threats that a distributed network could introduce. To mitigate this, it is critical to look for solutions that embrace a connected security paradigm that delivers insight into threats across the network while automating mitigation and enforcing security policies at the edge.
    • Limited technical skills and knowledge: A common perceived barrier to SD-WAN adoption is the concern that there is a significant learning curve for the technology and not enough existing skills to plan and manage it. This is a valid concern, though there are solutions. First, some SD-WAN providers offer managed services and can oversee deployment for customers through an outsourced or hybrid IT model. Second, organizations can invest in closing the skills gap via training. Though the latter option can be more time-consuming, investing in employees to learn the skills can help enterprises save money in the long run and move the industry forward by up-leveling important technical skills that are increasing in demand.

    Though there are notable barriers to SD-WAN adoption, there are also solutions for each one. If enterprises can overcome these barriers, implementing SD-WAN has the potential to improve scale, bring agility, unify policy and boost security efficacy through a collapsed and integrated AI-driven network. Deploying SD-WAN can be a significant investment for companies, but in the long run, the technology is an important step in moving enterprises into the next generation of networking.

  • Aruba Aims to Centralize Network Management

    Aruba Aims to Centralize Network Management

    Aruba, a unit of Hewlett-Packard Enterprise (HPE), unveiled orchestration software that makes it possible to centralize the management of network switches in the data center, across an extended campus and at the network edge.

    In addition, Aruba is adding a family of five 1/10/25/40/100 GbE switches to its portfolio that are designed to be deployed in the data center or network edge.

    Finally, Aruba is making available integrations for HPE ProLiant DL and DX servers as well as SimpliVity, Nimble, Synergy, Cray Shasta, Cray ClusterStor, SAP HANA, VMware and Nutanix platforms.

    William Choe, vice president of product management for Aruba, said Aruba Fabric Composer can also be coupled with HPE GreenLake, a managed service HPE provides to remotely manage HPE servers on behalf of customers.

    Based on a graphical interface, Aruba Fabric Composer is designed to make it possible for IT generalists to provision any type of switch, Choe said. The goal is to reduce the total cost of networking by enabling IT teams to centralize the management of switches regardless of whether they are a data center, campus or edge computing environment.

    With the rise of edge computing, the number of network switches that are being employed across a distributed computing environment is increasing. The challenge IT teams face is they can’t easily dispatch personnel to physically provision switches in remote locations at a time, as most IT staff members are working from home to help combat the spread of the COVID-19 pandemic.

    Aruba Fabric Composer, which is designed to be accessed via a VMware console, eliminates the need to manage enterprise networks in a piecemeal fashion, added Choe.

    Arguably, the centralization of network management is long overdue. Too many IT organizations are still managing each individual switch via a command-line interface (CLI) for each box. That not only makes managing a large network cumbersome, but it also creates a rigid IT environment that is unable to adroitly respond to rapid changes being made to the application environment. At a time when many organizations are trying to accelerate the deployment of applications needed to drive digital business transformation initiatives, legacy approaches to networking are hampering the modernization of IT.

    There are other networking equipment providers working to centralize the management of switches. However, it remains to be seen whether IT organizations are prioritizing the centralization of network management during the economic downturn brought on by the pandemic. But there is an absolute need to increase network bandwidth, so one way to justify an upgrade to the network is to make it less expensive to operate.

    As part of that effort, many organizations are also starting to converge network operations with best DevOps practices using application programming interfaces (APIs) and overlays such as service meshes to programmatically manage network underlays. Regardless of approach, the days when networks were managed by a dedicated team of specialists are on the wane.

  • How to Make a Self-Healing IT Infrastructure a Reality

    How to Make a Self-Healing IT Infrastructure a Reality

    In 2019, enterprises worldwide reported that every hour of infrastructure downtime cost them an average of $301,000- $400,000. If a system is down for five hours, that’s $1.5 million lost—and that’s on the low end. Five hours of downtime can impact companies for months down the road. It’s in the hands of DevOps practitioners to ensure systems are up and running and budgets are kept in line. But if they don’t have the proper tools on hand that allow them to juggle their responsibilities while adding value to the business, it makes their jobs that much more difficult—or, dare I say, impossible.

    Teams simply can’t afford to go offline to fix incidents, but neither can they afford to manually sift through data to find the root cause. By automating the incident management process, developers have more time to focus on building new products and capabilities that drive revenue. With a self-healing IT infrastructure, teams can tackle these issues before they become larger issues costing millions of dollars.

    Imagine you’re running to catch a bus and your heart rate increases, but when you sit down, it doesn’t come back down to a normal rate. This could quickly become a much larger, even fatal issue. In this instance, the body should “self-heal” to get back to a normal rate. On a similar note, a self-healing IT infrastructure allows teams to quickly get back on track by fixing issues before they become a $1.5 million problem.

    Let’s look at how DevOps practitioners can turn a self-healing IT infrastructure into a reality.

    Self-Healing Infrastructure Needs Observability and AI

    Observability is the practice of collecting deep data from applications and services to provide insights through three core components: logs, traces and metrics. While these three components are essential to a self-healing infrastructure, they are most powerful when used together. Similar to our senses of sight, hearing and touch, they each tell us something different but are equally important. When combining the power of all three, development teams can determine where, when and how an incident occurred and take action as needed.

    We all know the pain of traditional monitoring tools. They don’t surface immediate issues or identify root causes. They rely too heavily on developers to interpret and analyze immense amounts of data then sift through it in a tedious and time-consuming process requiring extra budget for more human power, and extra time to identify and remediate incidents. Using today’s cloud-native self-service approaches to combine observability and artificial intelligence, teams can set up tools themselves that automate the process of gathering and correlating metrics, logs and traces at machine speed to provide a complete, intelligent and actionable picture of what’s happening and why. And that’s where a self-healing IT system starts.

    The Future Is Within Reach

    By ingesting observability data, applying AI to analyze that data and create insights around root causes, then leveraging automation in a closed-loop, dev teams can not only see what’s happening but also take action on it for remediation. When this closed-loop process is done intelligently at machine speed, that’s when self-healing becomes a reality.

    The idea of a self-healing IT infrastructure doesn’t have to be a distant vision. In fact, the democratization of cloud computing and advanced data science have put the required observability technology within reach of teams of any size with any budget. When artificial intelligence and observability come together, DevOps practitioners can operate less and innovate more.

  • Intel Readies Gold oneAPI Toolkit

    Intel Readies Gold oneAPI Toolkit

    Intel this week said a gold image of its oneAPI for unifying infrastructure as code will be available starting next month.

    Jeff McVeigh, vice president of data center XPU products and solutions Intel, said the goal is to provide a standard application programming interface (API) for accessing the compute capabilities of any processor regardless of what company may have manufactured it.

    The availability of oneAPI coincides with the launch of a series of dedicated graphical processor units (GPUs) from Intel that are intended to supplant the dominance of NVIDIA.

    McVeigh said Intel is encouraging cloud service providers and builders of systems deployed on-premises to embrace oneAPI as a way to standardize the way any CPU, GPU, field-programmable gate arrays (FPGAs) or any other class of processor is incorporated within an environment rather than continuing to relying on programming models such as CUDA from NVIDIA that are designed for only one class of processor.

    The average developer may never interact directly with a low-level oneAPI, but McVeigh said a standard set of APIs at the processor level should ultimately serve to reduce the total cost of IT as developers invoke multiple classes of processors with their applications.

    Intel, of course, also sees oneAPI as an opportunity to usurp NVIDIA as the dominant providers of GPUs that are now widely employed in the cloud to train machine learning models. While Intel CPUs are still employed most to run the inference engine that enables those models to be deployed in a production environment, NVIDIA is now seeking to leverage its success in the cloud to provide either GPUs that can be used to run inference engines or processors from Arm. NVIDIA is in the process of acquiring Arm, a provider of processors that are widely employed in embedded system and edge computing environments.

    Microsoft and the open source contributors that oversees the development of the TensorFlow framework for building artificial intelligence (AI) applications have thus far endorsed oneAPI. In addition, the University of Illinois Beckman Institute for Advanced Science and Technology this week announced it is creating a oneAPI center of excellence (CoE) that will extend the oneAPI programming model to nanoscale molecular dynamics (NAMD) environments that employ code to simulate large biomolecular systems.

    Previously, the University of Stockholm (SeRC) has committed to adding support for oneAPI to GROMACS, open source software for building simulations of biomolecules, while Heidelberg University is working on adding support for oneAPI to GPUs from other vendors. Intel is also making available software based on oneAPI that is compatible with CUDA, added McVeigh.

    Finally, Intel also announced this week that the Intel Implicit SPMD Program Compiler (ISPC) will run on top of oneAPI Level Zero, which provides low-level, direct-to-metal interface. Written in X, ISPC is used to accelerate Intel OSPRay ray tracing engine on Intel CPUs. Support for ISPC on Intel GPUs is forthcoming.

    It may a little while before DevOps teams see the benefits of oneAPI; however, as it becomes easier to mix and match processors as they best see fit, chances are it’s because the overhead on the back end has been substantially reduced using a common API.

  • Cisco CEO: Developers Need More Infrastructure Control

    Cisco CEO: Developers Need More Infrastructure Control

    Cisco Systems CEO Chuck Robbins said this week that the company’s No. 1 priority going forward is to enable IT organizations to better manage application experience via abstraction layers that make to possible for developers to programmatically manage infrastructure.

    Speaking at its annual Cisco Partner Summit, which occurred online, Robbins said Cisco is working toward making it possible for developers to not only programmatically provision IT infrastructure but also impact how services are delivered using application networking services the company is currently developing.

    Over time, the entire Cisco portfolio will either be cloud-delivered or cloud-managed as Cisco increasingly delivers its technology as a service, he said. As part of that effort, Cisco is now exposing application programming interfaces (APIs) across its portfolio.

    At the core of the initiative are investments Cisco is making in AppDynamics, ThousandEyes and its Intersight IT operations management platform. Those tools will be employed to provide insights and observability across a diverse application environment that increasingly includes cloud-native applications running on Kubernetes clusters, Robbins said.

    In effect, Cisco is signaling a more aggressive transition toward managing infrastructure as code inside and out of the cloud. This week Cisco announced it has added an Intersight Workload Optimizer to optimize infrastructure consumption along with adding support for dynamic provisioning of Kubernetes clusters via Cisco Intersight. The company also added a Cisco Nexus dashboard to provide visibility into networks spanning multiple clouds, on-premises IT environments and edge computing platforms, and expanded the Cisco Identity Services Engine to now secure a wider variety of internet of things (IoT) endpoints.

    Cisco, like every other provider of IT infrastructure, is shifting toward a cloud operating model that promises to enable IT teams to manage on-premises IT infrastructure in the same way IT teams consume public cloud resources. As part of that effort, Robbins noted Cisco has been disaggregating all the software functionality it provides from hardware whenever possible, which will provide IT teams with more flexibility and control over highly distributed IT environments.

    The COVID-19 pandemic has only accelerated a transition to managing IT as service, as organizations rely more on applications to engage their end customers, he added.

    Of course, Cisco is not the only provider of IT infrastructure with similar ambitions. Not only is networking software is becoming accessible via APIs, but it’s also now possible to deploy a software-defined network on commodity processors almost anywhere. That transition is also the primary reason that network operations are increasingly being folded into DevOps teams seeking to manage compute, storage and networking as code across an extended enterprise.

    It may be a while yet before network and storage operations are fully assimilated into DevOps processes. However, it’s now no longer a question of if as much as how long before most IT organizations achieve that goal.

  • Dell Launches Project Apex to Deliver IT as a Service

    Dell Launches Project Apex to Deliver IT as a Service

    Dell Technologies today launched Project Apex, an initiative that promises to significantly expand its ambition to deliver IT as a service from the edge to the public cloud.

    Announced at the online Dell Technologies World 2020 conference, this initiative builds on the Dell Technologies Cloud Platform through which Dell manages IT infrastructure as service on behalf of customers.

    Sam Grocott, senior vice president of product marketing at Dell Technologies, said via a single pane of glass organizations will be able to deploy and manage application workloads running on IT infrastructure provided by Dell as well as public cloud service providers using the Dell Technologies Cloud Console, which is currently available as a public preview.

    In the first half of next year, Dell plans to roll out Dell Technologies Storage as a Service (STaaS) for on-premises IT environments, which also can be managed via the Dell Technologies Cloud Console.

    In addition, Dell is reducing the entry-level cost of its existing hybrid cloud offering built on top of Dell Technologies Cloud Platform to $47 per instance per month with a subscription, in addition to making the service available in the UK, France and Germany.

    Dell is also making a pre-approved Flex On-Demand pricing option that charges organizations on a usage basis for IT infrastructure, and has expanded its managed data protection services to include multiple public clouds.

    It’s not clear whether organizations will prefer to rely on Dell to manage their IT versus continuing to manage it themselves or rely on a third-party IT services provider. In theory, organizations will be able to invest more in application development that would eventually consume more IT infrastructure than is consumed today. However, it’s not clear internal IT organizations are prepared to cede control over IT infrastructure and applications to a single IT vendor, especially if they employ IT technologies provided by a broad spectrum of vendors.

    In the wake of the economic downturn brought on by the COVID-19 pandemic, however, Grocott noted the number of organizations that prefer to treat IT as an operational expense has increased substantially. In addition, with more employees working from home organizations are looking for a more flexible approach to IT that is a challenge for them to achieve relying on legacy systems. To facilitate that transition, Dell is expanding the refurbishment and recycling services it makes available to customers.

    In effect, Dell is enabling a cloud operating model to be applied to all of IT regardless of where applications or IT infrastructure is deployed.

    Of course, Dell is not the only IT platform provider with such ambitions. Not only are longtime rivals in the data center expanding the scope of the managed services they provide, but every major provider of a cloud service has also expanded the reach of their offerings to include on-premises and edge computing platforms. It may be a while before this titanic struggle for control over IT plays out, but the one thing that is for certain is the way IT is consumed is changing utterly.

  • Distributed Data and Apps: What About Your Infra?

    Distributed Data and Apps: What About Your Infra?

    Technological and operational shifts are required to accommodate the shift to distributed data and apps

    You’ve read how modern companies are disrupting their legacy peers by pursuing a data-driven culture …

    1. Chick-fil-A’s edge use case allows the company to transform its fast-food restaurants.
    2. An industry-first, software-only mobile infrastructure by Rakuten Mobile.
    3. Tesla Autopilot functionality getting ever so close to Level 5, with new features and enhancements pushed to vehicles almost bi-weekly.

    There are myriad, but the common thread is this: These are software-first companies in their categories. And why are they software-first? They are data-driven.

    Their secret sauce is the continuous pursuit to process and extract insights from data to drive their business decisions and operational efficiencies. So if that’s the recipe, why aren’t incumbents doing it?

    Distributed Data & Apps, Oh My!

    The Trend

    Data is becoming increasingly distributed in the enterprise, and for multiple reasons, including:

    • Digital transformation of business processes wherever they’re needed—at the branch, the factory, the store … even the car or plane.
    • The distribution of workloads and clusters themselves due to modern app architecture and deployment trends, including microservices, containers and multi-cloud.

    As a result, distributed apps and data in the enterprise typically require the following:

    • Real-time responses.
    • Hyper-localization (aka edge).
    • Near-zero downtime.
    • Intelligent management and security.

    To address the above, there are technological and operational shifts required. Those changes can be summarized below:

    What if We Have Legacy Infrastructure in Place?

    To recap: Apps are changing, driven by critical business needs. ← Read above.

    These changes have a significant impact on enterprise architectures in where apps run and how those apps and data are connected, secured and operated. The properties for dealing with the requirements of distributed apps and data are driving the following shifts:

    1. WHERE — Multiple Clouds and Edge
      Data gravity for performance reasons, risk reductions, edge AI use cases, etc.
    2. HOW — Hybrid Applications
      Containerization of apps and serverless environments, as well as the need to connect/discover legacy apps are driving new architectural, network and security challenges.
    3. HOW — Layer 3 (Network) → Layer 7 (App/Proxy/API)
      Connectivity is changing from traditional network-level (IP) access to app-to-app communication using REST/gRPC APIs which are usually delivered over HTTPS (TCP/443).

    Apps Have Changed. So Have the Required Capabilities for Networking and Securing Them

    • App-2-App Networking: Microservices and containers communicate to each other in addition to the end user and over wider locations, making reliability/performance an even greater consideration.
    • Higher-layer Security: App-to-app and microservices architectures require zero-trust at the API layer because that’s how they communicate.
    • API-first: Apps are written to be API producers and consumers on day 1. This has fundamental implications on how those APIs are delivered, connected and secured.

    To summarize: There are several technical and architectural trends (driven by business needs) around the types of applications, their locality and the means of how they are delivered/accessed. As they converge, it is creating major challenges for traditional networking, security and app services infrastructures.

    Why Today’s Infra Is Obsolete for Modern Apps

    Legacy Vendors, Limited Approaches = Mixed Results (at Best)

    Today’s enterprise architecture has become increasingly complex for app delivery

    OK, I’ll write what you’re thinking: Your router/switch vendor is obsolete. Your firewall is obsolete. Your load balancer/ADC is obsolete. The operational tools and services to manage this at scale are obsolete.

    When it comes to distributed apps and the need to process distributed data, traditional networking and security tools (and their operations) are unsustainable.

    Your Load Balancer/ADC Isn’t in Kansas Anymore …

    Legacy application delivery controllers or ADC (aka “the modern load balancer”) were designed to efficiently and securely deliver web-based monolithic apps directly to end users with the highest performance possible. They were:

    • Optimized for monolithic apps accessed directly by end users, whether SaaS and internet apps or enterprise web apps hosted in a public cloud or private data center.
    • Either hardware- or software-based, though recently evolved to software offerings such as NGINX and Avi, which can be deployed in multiple clusters and public clouds.
    • Limited in operational simplicity and end-to-end visibility when operating at scale in a distributed environment. They can’t be centrally managed (think SaaS) and don’t provide end-to-end observability across clusters, end-to-end policy management, etc.
    • Limited or no API capabilities. While newer software versions such as NGINX may have limited API gateway capabilities, most don’t. And none have API auto-discovery and control. Older ADCs were a combination of hardware or software solutions focused on delivering apps at L4 up to L7 from a traffic management basis. Modern apps have moved beyond this, and so must your app networking and security infra.

    Don’t believe me? Let me give you a real-world example to help calibrate where I’m coming from.

    Architecture for distributed HD mapping processing

     

    Above is an example architecture of an auto manufacturer looking to retrofit its existing and planned electric vehicle (EV) stations to collect HD mapping and process it at scale.

    Let’s analyze the workflow and requirements:

    1. EVs (taxis, rideshare and/or vehicles agreed to share and process data) drive in and a video sensor picks up on the make, model, VIN, license plate, etc.—any identifiable data.
    2. Query a backend database, typically hosted in a private cloud (for security and compliance reasons). Get the necessary credentials to access the vehicle’s local Wi-Fi.
    3. Offload the data to the EV station. Process locally what’s needed; the rest is sent to AWS for large-scale mapping analytics.
    4. Now add to this requirement that EV owners for business reasons or regulatory reasons would like to lease that EV compute to other automotive companies, law/government enforcement to access the EV stations in a secure, multi-tenanted and auditable way.
    5. Now multiply this need across 25,000 EV stations!

    The Oh Sh*t! Moment — Real-World Example

    There were multiple options and proposals put forward, insourced through various teams or outsourced through system integrators. Below is an example of one of those proposals:

    Traditional app networking architecture

     

    Let’s Summarize:

    • Infrastructure — 1 x public cloud vendor, 2 x private DCs, 5 x Software/Hardware Vendors (router/SD-WAN, firewall, load balancer, API gateway) across all locations (public, private and edge).
    • Application Management — 1 x vendor with inbuilt tooling for LCM of apps
    • Operational Model — Different tooling across environments (public, private and edge), different software/management systems for each vendor and service.
    • Configuration Models — Different configurations for services and vendors to achieve a holistic outcome.
    • Security/Auditing — Security across vertical software/vendor layers; along with horizontal visibility and management challenges (i.e. many locations).

    I’ll let someone else make the TCO on why the above is a nightmare (or this can be a topic for another post), but let’s assume for a moment you find a business model that actually works in your favor because you have an army of lawyers to make sure the vendors (the ones with deep pockets) bear the burden. But is this really a positive outcome for your business, employees or customers?

    Modern App Networking + Security for the Modern Enterprise

    A modern enterprise infra architecture for distributed apps

     

    A new generation of infrastructure platform (aka “modern”) is what’s needed for networking and securing modern apps, and it must be more app- and API-centric than your traditional ADCs. This is similar to how ADCs were an evolution of vanilla L4 load balancers over a decade ago.

    Here is a potential list of things to look for as you begin researching a modern infra stack and service for app networking and security:

    • Integrated stack for Layer 3-7 networking and security — a high-performance service that can be used to deliver secure app-2-app connectivity.
    • SaaS-first operations — everything from deploying a stack (site) to full lifecycle management of the software and its services. Think configuring a load balancer or reverse-proxy within minutes across 10,000 locations. Or a single pane of glass for your DevOps, NetOps, Dev and SecOps teams.
    • Intent-based policy — a single expression of intent across all layers starting from Layer 3 → 7 → API. A user can configure (and enforce) network connectivity, network firewall, forward proxy, load balancing, service policies, WAF, API Gateway (AuthZ/AuthZ, API service-2-service policies), etc.
    • End-to-end and bottoms-up observability — a single pane of glass for all teams to view metrics, logs and alerts from networking, firewalls, load balancers, API Gateway, etc.

    Here’s another example:

     

    Finishing Up

    To circle back, networking and security for modern apps requires a new kind of thinking … aka modern (or cloud-native) infrastructure. As apps become more distributed, your architecture, infrastructure and operations teams must adapt … and that includes modern app networking and security.

    This article is part of a series of articles from sponsors of KubeCon + CloudNativeCon 2020 North America