devopsy.kinsta.cloud

Tag: edge computing

  • How SASE Can Ease DevSecOps Adoption

    How SASE Can Ease DevSecOps Adoption

    DevSecOps is a software development methodology that merges development (Dev), security (Sec) and operations (Ops) into one team that integrates security throughout the entire software development life cycle (SDLC). The goal is to deliver high-quality applications quickly and securely.

    The traditional software development life cycle introduces security in the late phases of the SDLC. However, this approach cannot protect against sophisticated cybersecurity attacks. Today’s cybersecurity landscape requires shorter, frequent iterations to quickly patch and fix security issues. DevSecOps integrates security into the continuous integration and continuous delivery (CI/CD) pipeline to ensure teams can address pressing security issues at DevOps speed. 

    Many organizations are enthusiastically adopting DevSecOps but, in the process, discover they don’t have the necessary infrastructure. DevSecOps requires smooth global collaboration between teams and requires that security controls are built into the IT environment. This is where SASE comes in.  

    What is Secure Access Service Edge (SASE)?

    Secure access service edge (SASE) is a network security model that provides network connectivity with security based on identity, real-time security context and corporate security policies. It is aligned with the zero-trust security paradigm, ensuring that connections are denied by default unless a verified identity has permission to access a specific application, service or edge location. 

    SASE unifies networking and security functions into one fully integrated service delivered in the cloud. SASE includes several technologies: software-defined wide area networking (SD-WAN), secure web gateway (SWG), cloud access security broker (CASB), next-generation firewall (NGFW) and zero-trust network access (ZTNA).

    A key benefit of SASE is enhanced network security. SASE services enhance network security with a granular approach to network protection, detecting and blocking network attacks such as distributed denial of service (DDoS) attacks, man-in-the-middle (MitM) attacks, phishing, email spoofing and malware with deep security scans. 

    Additional benefits of SASE include: 

    • Lower cost compared to traditional networks because SASE includes fewer on-premises hardware components and features previously purchased from multiple vendors. 
    • Easier maintenance because it provides one pane of glass that allows IT teams to manage all applications and users wherever they are. 

    Components of SASE

    Cloud-access Security Broker (CASB)

    CASB acts as a bridge between users/devices and cloud applications. It allows organizations to apply security policies, two-factor authentication and single sign-on to all cloud applications, preventing unauthorized devices and individuals from accessing sensitive assets and denying access by default.

    Zero-Trust Network Access (ZTNA)

    ZTNA ensures that users or devices have explicit permission to access applications or resources. It is a critical component of a zero-trust security architecture, ensuring that internal, private applications are hidden from users who should not have access to them. It also enables secure remote access through layered authentication. ZTNA provides flexible security to meet modern security requirements.

    Software-Defined Wide-Area Networking (SD-WAN)

    SD-WAN is a connectivity architecture that separates network hardware from the physical control layer. It improves network performance by enhancing and simplifying WAN performance and management. SD-WAN supports modern, cloud-based applications and services while reducing connectivity costs. Combining SD-WAN with advanced security features provides a foundation for enterprises to transition to SASE.

    Secure Web Gateways (SWG)

    SWG protects online devices from malware infection, enforces corporate security policies and filters unwanted websites in user-initiated internet traffic. SWG provides URL filtering, application control, DLP, antivirus, sandboxing and SSL inspection. All these capabilities protect users from harmful websites and enforce security policies while ensuring full web access and promoting productivity.

    Firewall-as-a-Service (FWaaS)

    FWaaS is a firewall solution delivered as a cloud-based service. It provides hyperscale next-generation firewall (NGFW) features, including web filtering, advanced threat protection (ATP), intrusion prevention systems (IPS) and domain name system (DNS) security. By integrating FWaaS into the SASE platform, organizations can provide a wide range of cybersecurity capabilities at the edge.

    Centralized and Unified Management

    The modern SASE platform enables IT administrators to manage SD-WAN, SWG, CASB, FWaaS and ZTNA with centralized, unified management across networks and environments. This allows IT team members to focus on more pressing areas and improves the user experience for the organization’s mixed workforce.

    How SASE Will Impact DevSecOps and Security in Organizations

    SASE can help secure internal interactions and applications. As a result, the burden on DevSecOps teams is reduced. DevOps teams can use zero-trust network access (ZTNA) to further secure the applications running on SD-WAN. These technologies keep all interactions between endpoints and applications secure.

    The SASE model can also help protect mission-critical applications and sensitive data that cannot run on the public internet. To protect these assets, SASE obfuscates traffic, restricts access with a zero-trust architecture, and secures all network entry points with NGFW. It continuously evaluates application traffic for security threats.

    Facilitating Collaboration 

    DevOps teams are focused on time-to-market and are constantly working to accelerate the CI/CD pipeline. They need to collaborate remotely over a reliable and secure connection. DevOps teams are also working to reduce their reliance on network and security teams. The SASE model helps address these problems.

    SASE helps reduce collaboration issues by unifying WAN and network security. SASE solutions provide optimized performance and strong security, so DevOps teams don’t depend on infrastructure staff to provision resources. It gives teams full control over operations without compromising performance or security.

    Providing Built-In Security

    SASE offers the basic network security features required to secure a DevOps project. This allows teams to integrate different security mechanisms into their networking stack, with all security services sharing an integration context. This plugs the gaps in traditional security architecture often exploited by attackers and protects applications from threats.

    Improving Incident Response

    SASE can immediately block various attack vectors with security controls embedded in the network fabric, supporting the incident response team’s efforts. SASE increases visibility into behavioral anomalies and security incidents in a hybrid environment.

    Integrating SASE solutions into a security information and event management (SIEM) system allows incident responders to gain greater visibility into traffic anomalies and the automated security actions taken by the SASE tools. SASE features like NGFW, SWG, IPS and anti-malware might already contain or eliminate many incidents.

    Providing More Reliable Infrastructure 

    DevOps teams need fast, reliable application performance. SASE offers integrated load balancing and failover capabilities that can significantly improve the network’s overall performance. 

    The SASE architecture can connect all the edge devices, remote users, data centers and cloud resources to a secure, self-healing, fully optimized global network. If a circuit fails or the path becomes congested, the fabric can automatically switch to an alternate path.

    Conclusion

    In this article, I introduced DevSecOps and showed how SASE, a modern platform that provides fast network connectivity and security at the edge, can support its adoption. DevOps teams can use SASE security components to secure applications across on-premises data centers and clouds. SASE can encrypt and inspect traffic to protect it from threats, ensuring that workloads, users, and development systems are secure by default. 

    With SASE, DevSecOps teams have the infrastructure they need to secure the environment and can focus on integrating security tests and remediations into the development life cycle.

  • Fastly Adds Observability Tools for Edge Computing Environments

    Fastly Adds Observability Tools for Edge Computing Environments

    Fastly, Inc. this week added a set of observability tools to its portfolio that are optimized for edge computing platforms connected to its content delivery network (CDN).

    Laura Thomson, senior vice president of engineering at Fastly, said the company is now providing a set of tools that enable DevOps teams to capture logging data and metrics in real-time via a single console.

    The first two available tools are Origin Inspector—to observe network traffic flows including HTTPS response codes—and Domain Inspector—to access metrics based on both historical and real-time data. In total, Fastly is now providing access to more than 200 metrics spanning client, origin, cache, web application firewall (WAF), Compute@Edge, Image Optimization services and others that cover 100% of the data generated since the service was spun up.

    There is no sampling of data, and the company is also providing integrations with 33 storage and analysis services provided by either Fastly or a third party, noted Thomson. IT teams can now log any aspect of HTTP requests and responses through a large variety of logging formats, including the Common Log Format, JSON or as a key/value store. IT teams can also store their own logs to make sure they retain complete control over access.

    Over the next several months, Fastly will continue to expand this portfolio of observability tools, including an Edge Observer dashboard it is providing to customers that are deploying applications at the edge, added Thomson.

    In general, observability tools are being used to not only improve processes and overall customer experience but also identify and block suspicious activity. Fastly is making a case for observability tools that enable DevOps teams to achieve those goals without necessarily having to deploy a separate observability platform.

    Of course, most DevOps teams have been continuously tracking various pre-defined metrics for years. Observability tools, in contrast, are designed to make it feasible to interrogate logs, metrics and traces so that IT teams can discover issues before there is a disruption to services. The challenge, of course, is that not every IT team necessarily knows how to shape the queries required to discover the root cause of a potential issue.

    One way or another, DevOps teams will need to be able to remotely diagnose edge computing issues as the number of workloads deployed on these platforms expands. IT teams are not going to be able to travel to the physical location of every edge computing platform every time an issue arises. In many ways, the rise of edge computing will force a transition to observability tools that will enable IT teams to more proactively manage IT environments rather than respond after a metric has already exceeded its threshold.

    It’s not clear to what degree that approach will prevent IT issues from occurring, but the amount of time required to detect and remediate issues should dramatically decline as more visibility into IT environments, including edge computing platforms, is gained.

  • When the Cloud and the Edge Are the Same Thing

    When the Cloud and the Edge Are the Same Thing

    Edge computing remains a growing and exciting new architecture for enterprises across multiple industries. Distributing computing power across a decentralized network gives new opportunities for AI- and IoT-based applications. Demand is such that Gartner predicts by 2025, 75% of enterprise-generated data will be created and processed on the edge. 

    However, the cost and latency of sending all this data back to the cloud for processing are significant. To retain profitability, enterprises will need to keep as much data on the edge as possible while also moving processing to the edge. The benefits of these requirements are many, including:

    • Real-time processing, lower latency, faster answers
    • Resilience and availability, not relying on a stable connection to the cloud
    • More resource- and cost-efficient, less data shipping

    I believe organizations achieve these requirements and realize these benefits via a concept I call the cloud-to-edge data plane.

    A cloud-to-edge data plane unifies cloud and edge into a single solution that allows you to define your data and business logic once, package it up as a service and simply deploy it without having to worry if it should run in the cloud or out at the edge (which might change over time). This frees up the data plane automatically and adaptively to move services around, optimizing data access, coordination and replication, ensuring physical co-location of data, compute and user for the lowest possible latency with the highest throughput and availability.

    Choosing between cloud and edge is not a binary, black-and-white decision but has a lot of shades of gray in between. From an architectural perspective, the edge consists of many hierarchical layers between the cloud and the devices; each layer is further away from the cloud but closer to the end-users—a continuum. 

    Where you need your services to run in this continuum is very much use-case-dependent and might change over the lifetime of an application, depending on usage patterns or changes in features and business requirements. Critical parameters like latency, throughput, consistency, availability, scalability, compute resources, etc. change drastically as you move through this continuum. This results in both new opportunities and challenges:

    edge cloud

    One of the new services enabled by this architecture is mobile location transparent services. This new class of services is a thing of beauty. It means services are free to run anywhere and collaborate with other services without restrictions. It also allows the underlying platform to optimize overall system behavior by relocating services as needed, based on changes in usage, resources available, communication patterns, failure scenarios, and more. 

    If services are not location-transparent, then the system’s runtime topology needs to be part of the design and encoded into the services themselves. In practice, this means hardcoding decisions such as: 

    • If the communication between services is local or distributed—allowing for concurrency or distribution
    • If services are to be considered stationary or mobile—pinned to a specific physical address or free to be relocated
    • How the services can respond to failure—self-healing bulkheads that can be migrated to other nodes if needed or tied at the hip with the failed node

    Locking in decisions like this upfront will make the system harder to run efficiently, evolve, adapt and maintain over time. These should not be design or development decisions, not deployment decisions, but runtime decisions, not affecting the code. 

    It’s hard to predict the future. This includes knowing how an application will be used over time, how changes in usage and load patterns will evolve, and how future features or changes in business requirements will impact the initial design, assumptions, and runtime/operational characteristics. 

    Not having to take these decisions or worry about how they will be maintained efficiently but only focusing on API, data model, and business logic reduces time to market and overall risk substantially. 

    Here’s my vision for data…

    Data always exists wherever and whenever needed, but only for the time it is needed.

    • Having the latest and correct data always available to you right when you need it and wherever you happen to be located—in the central cloud or at the far edge—sounds like a developer’s dream.
    • On the other hand, it’s been said that “laziness is a virtue,” which is very much true of data management in a distributed system. Replicating data to locations where it will never be needed is a loss (unless needed for resilience/failover). The same is true for holding on to data longer than needed (holding resources hostage and forcing needless consistency mechanisms). 
    • Balancing this is very hard and should ideally be done by the platform adaptively at runtime at a global system level, rather than by the developer.

    Data is always co-located with processing and end-user—ensuring ultra-low latency, high throughput and resilience. 

    • If not, as in traditional three-tier stateless architecture, data is often somewhere other than where you need it to be and therefore has to be fetched before being used and pushed out to storage after modification. This increases latency, reduces throughput and puts the service at the mercy of the availability of the storage service.

    Data and compute move adaptively together with the end-user. 

    • Many use cases at the edge serve users on the move (e.g., cell phones, cars). To serve these users as efficiently as possible, their data and compute need to move geographically with them. 

    Data is injected into the services on an as-needed basis—automatically, timely, efficiently and intelligently. 

    • Data storage management is often very intrusive in application design and business logic: How to map domain objects to DB tables (OR-mapping), transaction management, storage API calls for fetching and updating the state, etc. 
    • Externalizing all of this to the platform and instead having the data injected into the service when new data is available (just as we are used to with events in a pub/sub system) makes the code easier to design, write, understand and maintain. 
    • Additionally, if the service is doing all data management itself, then it’s a black box to the platform. The platform has no idea what access patterns have been used, on what data, when data can be safely cached, replicated, sharded, prefetched, shared, etc. On the contrary, if the platform is doing all the data management, then it can look broadly across all services and safely optimize data management for the overall system holistically. 

    I believe RedMonk analyst Steve O’Grady’s concept of vertical integration fits well into this narrative. It all leads to what I feel is a distillation of a cloud-to-edge programming model (a continuum, as described previously). This model is about abstracting away everything that is not core business value, leaving the three things that can never be delegated: Data model, API and business logic. 

    As Timothy Keller said, “Freedom is not so much the absence of restrictions as finding the right ones, the liberating restrictions.”

    By using a serverless developer experience (DX), I believe the answer to extending real-time data and computing to the edge can be realized in a fully managed developer PaaS model. That model abstracts away all infrastructure into a single declarative programming model and effectively unifies cloud-native and edge-native development. This is “vertical integration” and the cloud-to-edge data plane vision.

    Conclusion

    Today, cloud computing and edge computing are typically treated as separate domains. However, rapidly evolving demands for intelligent low-latency processing of edge-generated data are creating requirements for a new approach combining cloud and edge into a single continuum. With cloud-native applications, architects and developers have already embraced the concepts required to build services that run in an essentially infinitely scalable (but logically centralized) cloud infrastructure. Extending this thinking to a fully decentralized infrastructure, including the edge, is a natural next step in enterprise application architecture. Programming models that enable a data-centric, location-transparent approach combined with intelligent runtimes that automatically enable data and processing to be co-located where and when needed will allow developers to take full advantage of such a wholly distributed edge-to-cloud environment.

  • Dell Launches Project Frontier Initiative to Advance Edge Computing

    Dell Launches Project Frontier Initiative to Advance Edge Computing

    Dell Technologies this week launched Project Frontier initiative that promises to make deploying software at the edge simpler using integrated platforms that will be available in 2023.

    Announced at a Dell Technologies Summit event, Project Frontier will create an integrated edge computing platform for vertical industry segments such as manufacturing and retail.

    Dell CEO Michael Dell told conference attendees these platforms will help customers simplify, optimize and scale their edge applications in a secure way.

    The offerings can be centrally managed either by an internal IT operations team or via managed services that Dell provides to simplify onboarding and ensure zero-trust security. The overall goal is to reduce the number of instances that might require IT personnel in the field to configure and update them.

    According to a 2022 IDC survey, 42% of businesses say the most challenging aspect of edge deployments is putting together an entire edge solution. To address that challenge, Dell is also launching a Dell Edge Design Program through which it will collaborate with customers to further advance edge computing solutions.

    Through its Dell Validated Design program, the company is already building edge computing platforms for specific customers, but the goal now is to make it simpler to deploy edge computing platforms at scale.

    The number of application workloads being deployed on edge computing platforms is rising sharply as organizations seek to process and analyze data closer to the point where it is created and consumed. In fact, that shift is at the core of many digital business transformation initiatives that depend on edge computing platforms and devices running, for example, internet of things (IoT) applications to process data in near-real-time.

    A major issue—and one that remains largely unsolved, in many cases—is that organizations lack the ability to consistently deploy software on edge computing platforms. That results in a hodgepodge of homegrown tools deploying software on a wide range of edge computing platforms using manual processes that don’t scale well.

    It’s too early to say just how much software will ultimately be deployed on the edge, but there may come a day when there is more software at the edge than there is in the cloud. Of course, the real challenge will be unifying the management of DevOps processes, regardless of where any given piece of software might be deployed. In fact, Dell is betting that as edge computing continues to evolve, the line between edge computing and cloud computing will continue to blur until they are little more than natural extensions of each other.

    Dell, of course, is not the only IT vendor that views edge computing as the next trillion-dollar IT opportunity. There is already no shortage of options. The issue will be determining which IT vendor has the most robust edge computing ecosystem. In the meantime, DevOps teams would be well-advised to revisit DevOps workflows now with an eye toward making sure they can truly scale. After all, as edge computing platforms continue to proliferate, their ability to build, deploy, update and secure software is about to be put to the ultimate test.

  • Distributed Systems: Turning Networking to Your Advantage

    Distributed Systems: Turning Networking to Your Advantage

    Whether it’s the office, the classroom, the store or the bank, a great many spheres of human life have moved online. Each day, we grow more and more used to consuming applications on demand that instantly connect us with the rest of the world. Our expanding appetite for the internet depends on an ongoing trend toward distributed systems, with most companies today spreading their information technology across hybrid and multi-cloud architectures that consist of small, independent and loosely coupled containers. Companies are scaling their applications by deploying more clusters of containers across an ever-broadening surface. There are four key lessons businesses can observe from the proliferation of distributed systems.

    Don’t Underestimate the Benefits of Distributed Systems

    There’s a reason why the trend toward distributed systems persists; they are chock full of benefits.

    Distributed systems are incredibly scalable, as they allow companies to scale applications by adding, replacing or removing nodes as necessary. New applications can be rolled out quickly and in multiple iterations, accelerating time-to-market. Codebases are smaller and easier to change. Distributed systems optimize developer efficiency and team collaboration because numerous teams can work on different parts of a system simultaneously.

    Distributed systems are highly resilient. When (and only when) built effectively, distributed systems will continue working even if a significant part shuts down, as traffic can be rerouted to functioning servers—just look at the resilience of the internet. Fewer single points of failure create more stability and fault tolerance.

    With so many benefits, it’s not difficult to see how distributed systems have enabled our connected, digital economy. Netflix is a prime example of how they have supported the growth of SaaS-based applications. Thanks to a complicated distributed system, anyone on Earth can access a massive library of movies, tv shows, and documentaries to stream whatever they want on demand, paying a monthly subscription.

    While Netflix is considered to be in the entertainment industry, we think of it as a technology company first and foremost because the success of its business model is based on the efficacy of its distributed system. Netflix’s platform is scalable, resilient, performant, efficient and therefore profitable because it is distributed.

    Know That Distributed Systems are Complex and Challenging

    Distributed systems are innately complex and therefore difficult to build and operate. They consist of many asynchronous components that must work in tandem with one another. As the system scales, it becomes even more challenging to understand, let alone operate.

    These challenges are hardly unique to Netflix. Any company that manages a distributed system at scale suffers because of the convoluted nature of distributed systems. Other internet giants like Spotify, YouTube and Twitter also grapple with compounding complexity. If you’re overwhelmed by the labyrinth that is your distributed system, take comfort in knowing that these challenges are (to an extent) unavoidable.

    Turn Networking to Your Advantage

    A distributed system is a set of computers, containers or any other nodes that connect to a network to communicate with other entities by passing messages. What truly allows distributed systems to be ‘distributed’ and to function is the network. This makes the network both a liability and an opportunity. Yes, even the best systems will fail at some point on various levels. There is no such thing as complete control in distributed systems, but that doesn’t mean you can’t turn networking to your advantage.

    Developers can efficiently manage their distributed system by prioritizing networking and employing the right tools across an architecture. Netflix has built exceptionally well-connected systems with servers deployed in thousands of locations worldwide that connect to the control plane in the cloud. If a server fails, traffic can easily be rerouted elsewhere. The distributed system is scalable, resilient, performant and efficient. Robust networking solutions give the team at Netflix visibility into and control over the application.

    Networking truly is the key to bolstering the advantages and overcoming the challenges of distributed systems. Invest resources in your network and it will take care of your distributed system.

    Aim for Simplicity

    Turn networking to your advantage by taking care when building a networking stack. The two most predictable pitfalls to avoid here are not choosing a stack that addresses your unique challenges and differentiators and selecting tools that are overly complicated for your use case.

    It’s all too common for companies building and managing distributed systems to adopt popular or default tools that come with their orchestration platform without giving their suitability much thought. It is never a good idea to copy-paste a networking stack seen elsewhere, assuming that what has worked for others will also work for you. It may, but do not blindly select the stacks everyone is talking about without giving them much thought.

    Many organizations followed the herd by adopting Istio, only to later discover that the service mesh is far too complicated and resource-intensive for their platform. While Istio’s numerous features are helpful for some, they quickly become burdensome. The trending tools are not necessarily the best for your use case.

    Some companies go the opposite route and build their own custom solutions instead of following the herd. Just as Netflix built Zookeeper for service discovery and Spotify built Backstage for API management cataloging, global companies with expansive distributed systems can benefit from the control offered by a custom tool. This option is expensive, time-consuming and not viable for non-tech or smaller companies.

    You’re (probably) not Netflix, so don’t try to be. You may think you have the same problems, but you don’t. Yes, distributed systems are always complex and full of challenges. But the complexity of distributed systems compounds at scale to such an extent that it becomes incomparable. Internet giants like Netflix and Spotify require the advanced features of complicated tools or custom solutions built in-house (and they have the means to invest in these resources). If your platform is a fraction of the size of Netflix’s, your distributed system relies on a far simpler network.

    It’s extremely easy to choose solutions that are overly engineered for your use case, but it’s best to opt for simpler alternatives. Start with simple solutions, gain control of your networking stack and then advance to another level of complexity later on. Gaining control of your network will allow you to tap into the benefits of distributed systems while avoiding some of the challenges. Turn networking to your advantage and make your infrastructure scalable by choosing simplicity over complexity.

  • The Benefits of a Distributed Cloud

    The Benefits of a Distributed Cloud

    The way applications are created has changed dramatically in just a few short years. It’s now all about rapid assembly and integration; applications built using microservices and containerized. Containers and the cloud have certainly been the catalyst for this progress and will continue to be the infrastructure on which developers create new and innovative applications. 

    As workloads are moving to the cloud, however, more and more businesses are realizing they need a cloud that can be rapidly adapted to their specific needs. Computing environments may be a blend of server types: On-premises, bare metal, colocated and distributed across multiple continents. No single cloud architecture can offer consistently exceptional application performance for all users.  

    Between hybrid, on-premises, multi-cloud, colocated, centralized and distributed clouds, it can be hard to keep all the terminology straight. What are the differences between these cloud architectures? Why use one rather than the other? In this article, we’ll focus on just one of these: The distributed cloud. 

    What is a Distributed Cloud?

    As opposed to the large public cloud where all computing is done in a central location, a distributed cloud consists of a system of servers that are not all in the same place—even though they are managed through a single cloud provider. The servers in a distributed cloud can be actually anywhere in the world. This allows for computing to be done closer to the end user, which improves the user experience in a multitude of ways.

    What Are the Advantages of Using a Distributed Cloud?

    Below are six of the key benefits of using a distributed, rather than a centralized, cloud.

    One Size Does Not Fit All

    Computing environments may be a blend of server types: On-premises, bare-metal, colocated and distributed across multiple continents. Cloud providers need to offer flexibility to customize a cloud for their end users and their business needs.

    Data Regulation Compliance

    Many countries have specific compliance requirements for their citizens’ data and do not allow for personal/financial data to be hosted outside of their borders. Thus, having a distributed server within those countries alleviates that issue. 

    Reduced Latency

    In a distributed cloud model, servers can be placed in a wide array of locations, including in an edge cloud. When servers are placed closer to end users as opposed to in a centralized location, data does not need to travel as far to get back to the server. 

    Improved CDNs

    A distributed cloud can be used to deploy content delivery networks, or CDNs, to speed up content and service delivery. Heavy content (e.g. videos) can be stored and delivered by the distributed cloud closer to end users, which enhances the user experience.

    Network Resilience

    Network connectivity is always a worry for cloud providers. If their system goes down, none of the user’s workloads will run. In a distributed cloud system, however, the network is at a reduced risk of failure because if the system crashes, cloud services can reside in a local subnet.

    Location Flexibility

    A distributed cloud can always become more distributed. More locations can be added to the network, broadening the global compute zones available within that cloud. Companies that want to reach users in specific locations around the world can use a distributed cloud to reach them.

    Changing How People Think About Cloud Computing

    To address the demand for versatility, a new type of cloud has emerged: The unified distributed cloud (UDC), in which workloads can run in thousands of locations anywhere on earth. Such a cloud connects to existing infrastructure around the world via one API. Businesses can enjoy the benefit of running workloads in multiple locations without needing to maintain any of the distributed infrastructure. From a single UI, users pick an existing data center to send their workloads to and, within minutes, begin deploying. 

    A UDC transforms heterogeneous infrastructure into a homogeneous cloud computing platform, which can then be leveraged to support the delivery of cloud services in proximity to end users. It is designed to be interoperable with any private, hybrid cloud or multi-cloud architecture. As a result, enterprises can create an optimized cloud computing strategy, taking advantage of existing and available infrastructure in the location—or locations—of their choosing.  And because it sits on existing infrastructure, it doesn’t require any additional capital expenditure.

    As opposed to the traditional cloud model, the UDC can change the way people think about the public cloud. While the large public cloud providers benefit from economies of scale, a distributed cloud takes advantage of the economies of locality and distribution and thus has the flexibility to handle emerging location-dependent apps, such as the new wave of internet-of-things applications.

  • Improving Observability With ML-Enabled Anomaly Detection

    Improving Observability With ML-Enabled Anomaly Detection

    Nowadays, DevOps and SRE teams have many tools to access and analyze logging data. However, there are two challenges that prevent these teams from resolving issues in a timely manner: 

    • They aren’t equipped with all the data they need
    • Detecting and resolving issues is reactive and manual

    In this article, I’m going to break down why these challenges persist and propose a new approach to observability that will help you overcome them.

    Observability Obstacles

    Challenge: You’re not analyzing all your log data

    DevOps and SRE teams need to understand the behavior of their applications and services to spot anomalies as they occur and keep them up and running. However, the cost of traditional logging platforms prevents these teams from analyzing 100% of their observability data. 

    Instead, they have adopted mechanisms to reduce ingestion volumes. In some cases, this means truncating or filtering out datasets. In others, it means moving data to a less active storage tier/target where analytics are not applied. Furthermore, engineers have to predict upfront which datasets are important and meet the criteria to index. It’s these datasets that teams have the ability to analyze in real-time. The rest are ultimately neglected.

    The net impact is that teams are left with an incomplete picture of their environment, making it difficult to understand how applications and services are behaving. As a result, they cannot pinpoint every issue as it occurs.

    Challenge: Traditional platforms create reactive and manual processes

    When working with traditional observability platforms, teams must constantly define logic to detect issues in their environment. And often, they are only able to detect the issues that they are aware of and have had time to build logic for. To keep alerts firing correctly, you have to stay on top of different data structures, changing data shapes, new schemas and libraries, and fluctuating baselines. 

    However, not every team is equipped to detect issues they haven’t seen before. When teams are faced with unknown behavior, they are left conducting a post-mortem debug which is inherently a reactive process. Furthermore, it is increasingly hard to resolve the issue quickly because logging data is often unstructured and difficult to search. Teams have to manually hunt through loglines to pinpoint the activity and affected systems or components. This approach can add hours or even days to an investigation.

    Improving Incident Response

    The solution: Machine learning-enabled anomaly detection and resolution

    To catch every issue and speed up incident investigations, teams can apply machine learning at the data source to detect potential threats and equip teams with the information they need to keep their applications and services running. This kind of approach allows engineers to analyze 100% of their log data and compile it in a consumable and actionable view so that they can spot changes in behavior and resolve anomalies quicker than the traditional approach.

    As loglines are created, they can be automatically analyzed and converted into insightful metrics that inform application and service behavior. From there, federated machine learning can be used to automatically detect and alert on an issue as it occurs. It does so by baselining key metrics, understanding when they’re outside of typical ranges, and determining the likelihood of anomalous behavior—all through machine learning.

    There is no need to continually build and refine logic, effectively eliminating overly manual engineering practices.

    When an issue occurs, developers and DevOps engineers will receive a detailed report of the specific changes in activity within their systems. In this report, they’ll see the exact window of time of the incident and the affected systems or metadata. This report also includes a pinpointed capture of the relevant raw data that contributed to the anomaly, as well as systems, components, or services that were involved.

    Finally, the relevant full-fidelity logs can be dynamically streamed to a central observability platform (Splunk, Datadog, etc.) before, during and after the anomaly. This gives teams the exact data they need to resolve the issue in a timely manner.

    In all, this kind of edge observability allows system administrators to analyze all of their logs all of the time—not just ones that match the pre-defined query in a centralized setup, saving tons of time when it comes to incident response.

  • How Stream Processing Goes Beyond Real-Time

    How Stream Processing Goes Beyond Real-Time

    How fast is real-time? According to Robert Miller’s 1968 seminal study on human-computer interaction, we perceive a response time of 100 milliseconds or less as instantaneous. This is much quicker than the average human reaction time, which one online test clocks at 273 milliseconds.

    Nowadays, customer-facing applications need to respond in as close to real-time as possible to win our attention and meet standard requirements. For example, 100 milliseconds is a golden rule for credit card processors to meet SLAs. Especially in our new remote-first economy, other areas like media, health care, retail and manufacturing need to take full advantage of real-time data processing to enhance digital business and stay relevant. Yet, leveling up with real-time requires some technical nuances that might be challenging to implement with the current developer skills gap.

    According to Manish Devgan, chief product officer at Hazelcast, the problem with most data management techniques is that data isn’t being processed in-stream at the edge. Instead, data gets stored and thrown into a data lake where it accumulates, unfulfilled. To make matters more complicated, decentralized data management means organizations may be overseeing many different data lakes, adding to the potential for unused data and increased latency.

    I recently met with Devgan to learn how in-memory stream processing goes beyond real-time data. According to Devgan, the secret sauce is processing incoming data in-stream while tying it to persistent storage to create context. By doing so, companies could unlock more innovative real-time experiences, he said.

    Use Cases For Real-Time

    Real-time presents many opportunities for business operations and end-user customer engagements. This is especially true in the financial sector. For example, Devgan explains how one bank was able to use real-time data at the moment of customer interaction at their ATMs. The system was able to fetch a history of the user account and extend an offer for a low line of credit, increasing their total loans by 400%. Capturing value at the moment of user intent is a golden opportunity, said Devgan.

    Capital One is another example of a financial institution leveraging advanced technology to improve the product experience. “They’re one of the leading banks in terms of technology,” said Devgan. Capital One’s threat detection system calls a machine learning model in real-time to detect and prevent fraud. Only by acting on incoming data in the moment of interaction can preventative responses like these be signaled.

    Other scenarios are also beginning to incorporate increased real-time analysis. “This split-second preemptive decision-making is important for many other use cases,” said Devgan. Physical retail might loop into customer loyalty programs at point-of-sale systems to increase in-store spending. Or, automobile manufacturers may want to use real-time processing to detect a problem with their robotic arms sooner rather than later.

    Real-time vs. Stream Processing

    When an event comes in, it usually has very little information. But when you look up a customer profile and connect it to a greater context, you can direct further actions. “Correlating data in motion with data at rest is where the magic happens,” Devgan. This distinction uncovers the difference between real-time data and stream processing.

    The real-time label tends to get thrown around a lot, and it’s quantified differently for different groups. Real-time might be five minutes for some applications but 10 milliseconds for others. Real-time could simply mean that a system accesses data at rest very quickly, delivering perceivably “real-time” results.

    On the other hand, stream processing incorporates data at rest and data in motion. It computes incoming, in-stream data and correlates it with data at rest. “You don’t let the data land — you process it as it comes in,” Devgan said.

    For years, enterprises have been collecting and storing exorbitant amounts of data. A survey by Seagate and IDC reveals that 43% of data collected is largely unleveraged and other studies estimate the amount of this “dark data” is over 50%. And, not acting upon data effectively makes it just another pile on top of the growing mountain of technical debt.

    There is a significant storage expense for holding on to too much data, whether on-premises or in the cloud. But, the paradigm is shifting a bit, said Devgan. Organizations don’t want to hold onto everything. The attitude is beginning to shift toward “garbage in, garbage out.”

    Technology Behind Real-Time Processing

    So, what sort of technology does stream processing require? Processing data at the edge requires some fundamental changes to design thinking. For one, since data must be computed in-stream, there’s more emphasis on in-memory processing. Devgan explained this as “pushing compute around instead of pushing data around.” To enable this, Devgan pointed to open-source projects like Jet that provide powerful distributed batch and stream processing.

    SQL has a storied history of acting upon data at rest. Now, Devgan said, he noticed the reemergence of SQL in a stream processing context. Though the industry is still defining how the SQL dialect will conform in a streaming world, he’s bullish on the prospect of SQL guiding this area. “Streaming SQL will be the lingua franca for streaming,” he insisted. We’re also in an early era of determining how to bridge the stateful and serverless worlds, Devgan added.

    But regardless of computing location, it will come down to the net customer experience outcomes. “People want to build their business applications and are less worried about the operational management of the system,” said Devgan. Whether it’s building real-time offers for e-commerce or implementing fraud detection, it will come down to the numbers. There is also a role for stream processing in health care to optimize physical resources and enhance patient experiences with real-time data. In all these scenarios, rapid access to data and processing at the edge will determine much of their success.

  • What Developers Need to Know About Edge Computing

    What Developers Need to Know About Edge Computing

    More and more companies are living “on the edge” as they move from “I’ll think about edge computing” to “I don’t think our business can optimally grow and compete without edge computing.” Developers will play a key role in helping organizations use the edge, but their effectiveness will depend on having edge-aligned processes, products and people in place.

    Edge computing takes place near the physical location of either the user or a data source. It’s one way that organizations can use and distribute a common pool of resources across multiple locations. The edge model provides users with faster, more reliable services while expanding the potential of hybrid cloud computing for organizations. Customers and businesses alike will benefit from the way in which edge computing optimizes the use and application of artificial intelligence and machine learning by running data-intensive applications closer to the data source.

    While it is in many ways a question of architecture, applications are key to effectively exploiting the edge. Here are some of the things developers—and their organizations—need to know.

    Edge computing and cloud computing are not mutually exclusive. The best solutions will leverage both platforms. For example, centralized computing might be used for storage and compute-intensive workloads, while edge computing would be used to exploit data at the source, in near-real-time. Infrastructure and company culture need to be in place to support this, but developers must be thinking in terms of building applications that can cross and bridge computing platforms.

    Consistent tooling is essential. Developing for legacy IoT was very specific and required specialized tools and skills. The modern edge, in contrast, is part of a technology continuum, and developers need tools that they can use across that continuum, including:

    • Provider/enterprise core: The “non-edge” tiers, owned and operated by public cloud providers, telco service providers or large enterprises.
    • Service provider edge: Tiers are located between the core or regional data centers and the last mile access.
    • End user premises edge: Tiers on the end-user side of the last mile access can include the enterprise or the consumer edge.
    • Device edge: Standalone (non-clustered) systems that directly connect sensors/actuators via non-internet protocols. This represents the far edge of the network.

    Containerization enables flexibility, scale: Linux container technology wasn’t built for the edge, but the model fits perfectly with edge requirements for modularity, segregation and immutability. 

    Keep an “open” mind. Open APIs open up new opportunities. Developers using open APIs can access real-time data programmatically, making it possible to build applications that can leverage data as it’s “born.” Likewise, a focus on open source development tools and platforms will help to ensure that organizations can continue to leverage the edge as the model evolves. 

    What’s different is the devices. Developing for the edge is just like developing for any other platform–except that developers must write consistent and secure code that can be seamlessly copied to all device types. 

    Edge computing may not start with developers, but developers will play a huge role in organizations’ ability to leverage the edge. A focus on flexibility, openness and the future will help ensure that developers build applications that fully exploit and expand the edge advantage. 

  • Eclipse Foundation Launches Open Source Edge Computing Initiative

    Eclipse Foundation Launches Open Source Edge Computing Initiative

    The Eclipse Foundation in collaboration with the OpenAtom Foundation today launched the Oniro project and working group to create an independent implementation of OpenHarmony, an open source operating system.

    Created by the OpenAtom Foundation, the OpenHarmony operating system is based on a HarmonyOS originally created by Huawei. It is designed to support multiple kernels but uses the Linux kernel if a device has a large amount of memory.

    It also includes a DSoftBus capability for integrating physically separate devices into a single logical super device that enables one device to control others in addition to facilitating data sharing among distributed devices.

    Huawei, in collaboration with Linaro, Seco, Array, NOITechPark and Synesthesia, has also been contributing to a continuous integration/continuous delivery (CI/CD) platform that is part of the larger Oniro project.

    Mike Milinkovich, executive director of the Eclipse Foundation, said the goal is to provide a common layer of abstraction platform that can be employed across a wide range of embedded systems that are typically being deployed at the network edge. That level of fragmentation surrounding platforms that don’t provide a lot of significant differentiated value only results in slowing down the deployment of applications, noted Milinkovich.

    As part of that effort, a dedicated working group has been created to provide a vendor-neutral structure through which contributions to the project can be made with greater transparency. The OpenAtom Foundation was created in Beijing last year with the support of Alibaba, Baidu, Huawei, Inspur, Qihoo, Tencent and China Merchants Bank. The alliance with the Eclipse Foundation brings more traditional governance rules for building open source software to the OpenHarmony project.

    In general, DevOps teams should be tracking the development of proposed de facto standards for edge computing platforms closely. More applications are now being deployed on edge computing platforms that make it possible to process and analyze data at the point where it is being created and consumed. The DevOps challenges associated with building and deploying applications across a highly distributed computing environment are considerable.

    In many cases, organizations that never really attempted or mastered continuous delivery of applications and their associated updates will be sorely challenged when it comes times to support hundreds, possibly thousands of applications, running on embedded systems based on a wide range of processors.

    In addition, many of those same DevOps teams will start to see traditional batch-oriented applications being superseded by applications based on event-driven architectures that process data in near-real-time. In most cases, those applications are going to be built on microservices-based applications that are typically more challenging to build and deploy than a traditional monolithic application.

    Arguably, IT organizations are on the cusp of a new era of IT that assumes most organizations have not only mastered DevOps best practices but are now also embracing DevSecOps best practices to secure those application environments.

    It may be a while before the open source software that will be developed by the Orino project finds its way into production environments, but it should be apparent that reducing complexity at the network edge should be a high priority for all DevOps teams heading into 2022.