Tech Kaizen: CLOUD COMPUTING

Showing posts with label CLOUD COMPUTING. Show all posts

FIDO Device Onboard (FDO)

FIDO Device Onboard (FDO), sometimes called 'device provisioning,' is a Specification for Automated, Secure IoT Provisioning Technology leveraging asymmetric public key cryptography to provide the industrial IoT industry with a fast and secure way to onboard any device to any device management system.

What is "Device Onboarding"?
Device onboarding is the process of installing secrets and configuration data into a device, so it can connect and interact securely with an IoT platform. An IoT platform could range from an application on a user’s computer, phone or tablet, to an enterprise server, to a cloud service spanning multiple geographic regions. The device owner uses the IoT platform to manage the device by patching security vulnerabilities, installing or updating software, retrieving sensor data, interacting with actuators, and more.

FDO is invoked autonomously and performs only limited, specific, interactions with its environment to complete. A unique feature of FDO is the ability for the device owner to select the IoT platform at a late stage in the device life cycle. The secrets or configuration data may also be created or chosen at this late stage, with a feature called “late binding”.

ref:

1. https://fidoalliance.org/intro-to-fido-device-onboard

2. FIDO Device Onboard Specification - https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-RD-v1.0-20201202.html

3. https://www.embedded.com/fido-device-onboarding-integrated-into-iot-identity-access-management/

4. https://www.redalertlabs.com/blog/top-10-things-you-should-know-about-fido-device-onboarding-fdo

Secure Access Service Edge(SASE)

Secure Access Service Edge, also known as SASE -- pronounced "sassy" is a cloud architecture model that bundles network and security-as-a-service functions together and delivers them as a single cloud service. A SASE approach offers better control over and visibility into the users, traffic, and data accessing a corporate network - vital capabilities for modern, globally distributed organizations. Networks built with SASE are flexible and scalable, able to connect globally distributed employees and offices across any location and via any device.

A SASE architecture combines a software-defined wide area network (SD-WAN) or other WAN with multiple security capabilities (e.g., cloud access security brokers, anti-malware), securing your network traffic as the sum of those functions. SASE provides a simple security and networking tool that is independent of where employees and resources are located. SASE requires little to no hardware, using the widespread connectivity of cloud technology to combine SD-WAN with network security functions, including:

firewall as a service (FWaaS)
software as a service (SaaS)
secure web gateways (SWG)
cloud access security broker (CASB)
zero-trust network access (ZTNA)

How does SASE compare to traditional networking?
In a traditional network model, data and applications live in a core data center. In order to access those resources, users, branch offices, and applications connect to the data center from within a localized private network or a secondary network that typically connects to the primary one through a secure leased line or VPN. Due to the rise of distributed workforces, It is no longer practical to reroute all traffic through a centralized data center if applications and data are hosted in the cloud.

By contrast, SASE places network controls on the cloud edge — not the corporate data center. Instead of layering cloud services that require separate configuration and management, SASE streamlines network and security services to create a secure network edge. Implementing identity-based, Zero Trust access policies on the edge network allows enterprises to expand their network perimeter to any remote user, branch office, device, or application.

ref:

1. https://www.cloudflare.com/learning/access-management/what-is-sase/

2. https://www.techtarget.com/searchnetworking/definition/Secure-Access-Service-Edge-SASE

3. https://www.zscaler.com/resources/security-terms-glossary/what-is-sase

Uber Cadence

Uber Cadence is a fault-tolerant stateful Workflow Orchestrator. Workflows provide primitives to allow application developers to express complex business logic as code. The underlying platform abstracts scalability, reliability and availability concerns from individual developers/teams. It is open-source, developed by Uber and written in Go language. Define workflows in the code and Cadence will make sure that the whole workflow code will execute no matter what!

Cadence is a distributed, scalable, durable, and highly available orchestration engine developed at Uber Engineering to execute asynchronous long-running business logic in a scalable and resilient way. The unit of work that you can execute with a Cadence client is the Workflow . This is basically a Go function, which describes the main flow, precedence, branching, or, for example, iterations of actions. However there are some rules that you have to follow to get a correct and reliable behavior. Workflow encapsulates the orchestration of activities and child workflows.

The workflow is the implementation of the coordination logic. The Cadence programming framework (aka client library) allows you to write the workflow coordination logic as simple procedural code that uses standard Go data modeling. The client library takes care of the communication between the worker service and the Cadence service, and ensures state persistence between events even in case of worker failures. An activity is the implementation of a particular task in the business logic. Activities are implemented as functions. Data can be passed directly to an activity via function parameters.

What makes Cadence different?

What makes Cadence more than a sophisticated distributed task queue manager? You can define workflows in code and let Cadence handle state, timeouts, history and all the other little necessities. Then, those workflows can be inspected after submission, so you can check their progress and results, or send them external signals as needed.

Cadence fault-oblivious stateful code platform preserves a complete multithreaded application state including thread stacks with local variables across hardware and software failures. It greatly simplifies the coding of complex stateful distributed applications. At the same time, it is scalable and robust enough to power hundreds of critical use cases.

Microservice Orchestration and Saga:

The Saga Pattern is a microservices architectural pattern to implement a transaction that spans multiple services. A saga is a sequence of local transactions. Each service in a saga performs its own transaction and publishes an event. The other services listen to that event and perform the next local transaction.

It is common that some business processes are implemented as multiple microservice calls. And the implementation must guarantee that all of the calls must eventually succeed even with the occurrence of prolonged downstream service failures. In some cases, instead of trying to complete the process by retrying for a long time, compensation rollback logic should be executed. Saga Pattern is one way to standardize on compensation APIs.

Cadence is a perfect fit for such scenarios. It guarantees that workflow code eventually completes, has built-in support for unlimited exponential activity retries and simplifies coding of the compensation logic. It also gives full visibility into the state of each workflow, in contrast to an orchestration based on queues where getting a current status of each individual request is practically impossible.

ref:

Uber Cadence - https://cadenceworkflow.io/

Cadence github - https://github.com/uber/cadence

Cadence Get started - https://cadenceworkflow.io/docs/get-started/

Cadence usecases - https://cadenceworkflow.io/docs/use-cases/

Cadence Go Client - https://github.com/uber-go/cadence-client

Cadence Go client samples - https://github.com/uber-common/cadence-samples

Introduction to Cadence - https://banzaicloud.com/blog/introduction-to-cadence/

Uber Codence overview - https://eng.uber.com/open-source-orchestration-tool-cadence-overview/

Cadence workflow orchestrator - https://blog.usejournal.com/cadence-the-only-workflow-orchestrator-you-will-ever-need-ea8f74ed5563

Building your first Cadence Workflow - https://medium.com/stashaway-engineering/building-your-first-cadence-workflow-e61a0b29785

Saga pattern - https://microservices.io/patterns/data/saga.html

Cadence implementation of Saga pattern - https://github.com/uber/cadence-java-client/blob/master/src/main/java/com/uber/cadence/workflow/Saga.java

Misc -

1. Uber Cadence workflow orchestrator engine - https://uber-cadence.blogspot.com/2019/12/how-do-i-set-up-uber-cadence-workflow.html

2. Building Reliable Workflows: Cadence as a Fallback for Event-Driven Processing - https://doordash.engineering/2020/08/14/workflows-cadence-event-driven-processing/

3. Uber Cadence & Kubernetes - https://hub.kubeapps.com/charts/banzaicloud-stable/cadence

Temporal workflow - https://temporal.io/

Temporal github - https://github.com/temporalio, https://github.com/temporalio/temporal

Cadence and Temporal Workflow Engines - https://github.com/firdaus/awesome-cadence-temporal-workflow

Temporal documentation - https://docs.temporal.io/docs/get-started/

Apache Kafka

Apache Kafka is a framework implementation of a software bus using stream-processing. It is an open-source distributed event streaming platform to provide a unified, high-throughput, low-latency platform for handling real-time data feeds(high-performance data pipelines), streaming analytics, data integration, and mission-critical applications. Kafka is an open-source software platform developed by the Apache Software Foundation written in Scala and Java.

Apache Kafka was built with the vision to become the central nervous system that makes real-time data available to all the applications that need to use it, with numerous use cases like stock trading and fraud detection, to transportation, data integration, and real-time analytics. It is a distributed streaming platform with plenty to offer from redundant storage of massive data volumes, to a message bus capable of throughput reaching millions of messages each second. These capabilities and more make Kafka a solution that’s tailor-made for processing streaming data from real-time applications.

Kafka is essentially a commit log with a very simplistic data structure. It just happens to be an exceptionally fault-tolerant and horizontally scalable one. The Kafka commit log provides a persistent ordered data structure. Records cannot be directly deleted or modified, only appended onto the log. The order of items in Kafka logs is guaranteed. The Kafka cluster creates and updates a partitioned commit log for each topic that exists. All messages sent to the same partition are stored in the order that they arrive. Because of this, the sequence of the records within this commit log structure is ordered and immutable. Kafka also assigns each record a unique sequential ID known as an “offset,” which is used to retrieve data.

Kafka Terminology:

Kafka uses its own terminology when it comes to its basic building blocks and key concepts. The usage of these terms might vary from other technologies. The following provides a list and definition of the most important concepts of Kafka:

Broker
A broker is a server that stores messages sent to the topics and serves consumer requests.

Topic
A topic is a queue of messages written by one or more producers and read by one or more consumers.

Producer
A producer is an external process that sends records to a Kafka topic.

Consumer
A consumer is an external process that receives topic streams from a Kafka cluster.

Client
Client is a term used to refer to either producers and consumers.

Record
A record is a publish-subscribe message. A record consists of a key/value pair and metadata including a timestamp.

Partition
Kafka divides records into partitions. Partitions can be thought of as a subset of all the records for a topic.

ref:

Apache Kafka - https://kafka.apache.org/

Kafka github - https://github.com/apache/kafka

Confluent(Real-time streams powered by Apache Kafka) github - https://github.com/confluentinc

zeromq vs kafka - https://www.educba.com/zeromq-vs-kafka/

Kafka architecture -

1. https://www.instaclustr.com/apache-kafka-architecture/

2. https://data-flair.training/blogs/kafka-architecture/

3. https://dzone.com/articles/kafka-architecture

4. https://docs.cloudera.com/runtime/7.2.7/kafka-overview/topics/kafka-overview-architecture.html

Fundamentals of Apache Kafka - https://www.confluent.io/online-talks/fundamentals-for-apache-kafka

How Kafka works - https://www.confluent.io/online-talks/how-apache-kafka-works-on-demand/

Confluent Platform Reference Architecture for Kubernetes - https://www.confluent.io/resources/confluent-platform-reference-architecture-kubernetes/

How to download Kafka code - https://kafka.apache.org/code

Kafka go clients -

1. Uber Kafka client - https://github.com/uber-go/kafka-client

2. Confluent Kafka client - https://github.com/confluentinc/confluent-kafka-go

3. Segmentio Kafka client - https://github.com/segmentio/kafka-go

Kafka Python Client - https://github.com/dpkp/kafka-python

Kafka examples -

1. kafka examples - https://github.com/confluentinc/examples

2. kafka stream examples - https://github.com/confluentinc/kafka-streams-examples

Principles of Cloud-native Architecture

Cloud-native architecture is the design or plan for applications and services built specifically to exist in the cloud. Most resources emphasize the role of microservices in cloud-native architecture.The major advantage of cloud-native architecture over legacy systems is its flexibility.

Cloud-native architectures aren’t built on on-premise physical servers but are instead deployed on a cloud platform and leverage the cloud philosophy of distributed systems. This enables cloud-native architectures to take full advantage of the latest and best technologies around distributed systems. They are specifically designed to utilize the versatility and scalability benefits of the cloud.

The best way to understand cloud-native architecture is to take a closer look at cloud-native applications. Cloud-native apps are built on a fundamentally different approach than monolithic applications. Rather than developing and deploying the application as a whole, cloud-native apps are based on microservices that are self-contained and independently deployable.

Microservices are the core of cloud-native application architecture. They are essentially small, self-sufficient mini-programs, each with their own data store and application logic, built to execute a single business function. Cloud-native architecture will consist of many small pieces that work together. You can change, add, or replace one without potentially breaking the entire system.

Cloud-native architecture typical components include:

These pieces work together, but you can tinker with them independently without taking down the entire system. Your final build is scalable, resilient, and available to all consumers.

Traditional vs Cloud Computing Environments:

In a traditional computing environment, a company needs to provision capacity based of their best guess of a maximum peak traffic (for instance - Black Friday). Which means that for extended periods of time, a vast majority of your capacity is essentially wasted.

This is more or less why Cloud Computing was born - you get to use other's extra capacity for your own purposes. Servers, databases, storage etc. can be started and shut down within hours or even minutes based on the requirements.

5 Principles of cloud-native Architecture:

Principle 1: Design for automation
1. Continuous Integration/Continuous Delivery

2. Scale up and scale down

3. Monitoring and automated recovery - black-box monitoring and white-box monitoring

Principle 2: Be smart with state
1. Stateless components(containers) - Stateless means that any state (persistent data of any kind) is stored outside of a container

2. Immutable components(containers) - Immutable means that a container won't be modified during its life: no updates, no patches, no configuration changes.

Principle 3: Favor managed services

Principle 4: Practice defense in depth - Adopt an approach of defense-in-depth by applying authentication between each component, and by minimizing the trust between those components (even if they are 'internal'). As a result, there is no 'inside' and 'outside'.

Principle 5: Always be architecting - Always seek to refine, simplify and improve the architecture of the system, as the needs of the organization change, the landscape of your IT systems change, and the capabilities of your cloud provider itself change.

ref:

Cloud-Native Architecture - https://www.okta.com/identity-101/what-is-cloud-native-architecture/

- https://cloud.google.com/blog/products/application-development/5-principles-for-cloud-native-architecture-what-it-is-and-how-to-master-it

- https://medium.com/@ranosys/7-best-cloud-architecture-practices-you-must-know-d2051c2007fa

- https://cloud.google.com/solutions/best-practices-for-operating-containers#immutability

Design components to be stateless and immutable - https://cloud.google.com/solutions/best-practices-for-operating-containers#immutability

Architecting for the Cloud(AWS Best Practices) -

1. https://d1.awsstatic.com/whitepapers/AWS_Cloud_Best_Practices.pdf

2. https://tlakomy.com/architecting-for-the-cloud-aws-best-practices-part-1

Cloud Design Patterns

A software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context. The architectural patterns address various issues in software engineering, such as computer hardware performance limitations, high availability and minimization of a business risk.

Cloud computing is the on-demand availability of computer system resources, especially data storage and computing power, without direct active management by the user. The term is generally used to describe data centers available to many users over the Internet. Cloud computing architecture refers to the components and sub-components required for cloud computing. These components typically consist of a front end platform (fat client, thin client, mobile ),back end platforms (servers, storage), a cloud based delivery, and a network (Internet, Intranet, Intercloud). Combined, these components make up cloud computing architecture.

Cloud Development Challenges:

1. Availability - Availability is the proportion of time that the system is running, functional and working, usually measured as a percentage of uptime. It can be affected by system errors, infrastructure problems, malicious attacks, and system load.

2. Performance & Scalability - Performance is an indication of the responsiveness of a system to execute any action within a given time interval, while scalability is ability of a system either to handle increases in load without impact on performance or for the available resources to be readily increased.
Cloud applications typically encounter variable workloads and peaks in activity. Instead, applications should be able to scale out within limits to meet peaks in demand, and scale in when demand decreases. Scalability concerns not just compute instances, but other elements such as data storage, messaging infrastructure.

3. Management and Monitoring - Cloud applications run in a remote data-center(hybrid/public/private) where you do not have full control of the infrastructure or, in some cases, the operating system. This can make management and monitoring more difficult than an on-premises deployment. Applications must expose runtime information that administrators and operators can use to manage and monitor the system, as well as supporting changing business requirements and customization without requiring the application to be stopped or redeployed.

4. Security - Security is the capability of a system to prevent malicious or accidental actions outside of the designed usage, and to prevent disclosure or loss of information. Cloud applications are exposed on the Internet outside trusted on-premises boundaries, are often open to the public, and may serve untrusted users. Applications must be designed and deployed in a way that protects them from malicious attacks, restricts access to only approved users, and protects sensitive data.

Popular Cloud Design Patterns:

1. Asynchronous Request-Reply

2. Ambassador

3. Sidecar

4. Publisher-Subscriber

ref:

Wiki -

1. https://en.wikipedia.org/wiki/Cloud_computing

2. https://en.wikipedia.org/wiki/Cloud_computing_architecture

Hybrid and multi-cloud architecture patterns - https://cloud.google.com/solutions/hybrid-and-multi-cloud-architecture-patterns

AWS Cloud Design Patterns -

1. http://en.clouddesignpattern.org/index.php/Main_Page

2. https://www.bmc.com/blogs/aws-cloud-design-patterns/

Cloud Design Patterns Misc -

1. https://medium.com/@maheshsonaiya/cloud-design-patterns-cac98e878698

2. https://levelup.gitconnected.com/cloud-design-patterns-explained-simply-113c788b33ff

Cloud Design Patterns - https://www.cloudcomputingpatterns.org/

Books -

1. Cloud Design Patterns Book from Microsoft -

1. https://download.microsoft.com/download/B/B/6/BB69622C-AB5D-4D5F-9A12-B81B952C1169/CloudDesignPatternsBook-PDF.pdf(pdf download)

2. https://docs.microsoft.com/en-us/azure/architecture/patterns/ (online)

    2. Designing Distributed Systems - https://azure.microsoft.com/mediahandler/files/resourcefiles/designing-distributed-systems/Designing_Distributed_Systems.pdf

    3. Distributed Systems Concepts and Design(5th Edition) - https://github.com/rangaeeeee/books-os/blob/master/Distributed%20Systems%20Concepts%20and%20Design%20-%205th%20Edition.pdf

    4. Free-OReilly-Books - https://github.com/mohnkhan/Free-OReilly-Books

Youtube Videos -

1. Distributed Architecture Patterns - https://www.youtube.com/watch?v=tpspO9K28PM

2. Cloud Architecture - https://www.youtube.com/watch?v=TuZZIGSbFfQ

3. Architectural patterns for the cloud(Mahesh Krishnan) - https://www.youtube.com/watch?v=TuZZIGSbFfQ

4. Cloud Security - https://www.youtube.com/watch?v=4TxvqZFMaoA

The Lightweight Kubernetes Distribution Built for the Edge - k3s

K3s is a lightweight, easy to install Kubernetes distribution geared towards resource-constrained environments and low touch operations. Some use cases in which k3s really shines are edge, ARM, IoT, and CI.

K3s from Rancher Labs is packaged as a single binary which is about 40 megabytes in size. Bundled in that single binary is everything needed to run Kubernetes, including the container runtime and any important host utilities like iptables, socat, and du. The only OS dependencies are the Linux kernel itself and a proper dev, proc, and sysfs mounts (this is done automatically on all modern distros). Cloud Native Computing Foundation (CNCF) has accepted the K3s as its Sandbox project in Aug'2020.

What is K3s?:
K3s is a fully compliant Kubernetes distribution with the following enhancements:

Packaged as a single binary.
Lightweight storage backend based on sqlite3 as the default storage mechanism. etcd3, MySQL, Postgres also still available.
Wrapped in simple launcher that handles a lot of the complexity of TLS and options.
Secure by default with reasonable defaults for lightweight environments.
Simple but powerful “batteries-included” features have been added, such as: a local storage provider, a service load balancer, a Helm controller, and the Traefik ingress controller.
Operation of all Kubernetes control plane components is encapsulated in a single binary and process. This allows K3s to automate and manage complex cluster operations like distributing certificates.
External dependencies have been minimized (just a modern kernel and cgroup mounts needed). K3s packages required dependencies, including:

Containerd
Flannel
CoreDNS
CNI
Host utilities (iptables, socat, etc)
Ingress controller (traefik)
Embedded service loadbalancer
Embedded network policy controller

ref:

K3s, Lightweight Kubernetes - https://rancher.com/docs/k3s/latest/en/, https://www.infoworld.com/article/3342125/rancher-k3s-brings-kubernetes-to-iot-devices.html

K3s Architecture - https://rancher.com/docs/k3s/latest/en/architecture/

K3s github source code - https://github.com/rancher/k3s

K3s overview - https://rancher.com/blog/2019/2019-02-26-introducing-k3s-the-lightweight-kubernetes-distribution-built-for-the-edge/

Build a Kubernetes cluster using k3s via Ansible - https://github.com/rancher/k3s-ansible

Develop your cloud native use cases at the edge with K3s - https://www.cncf.io/webinars/develop-your-cloud-native-use-cases-at-the-edge-with-k3s/

Rancher Labs’ K3s Joins Cloud Native Computing Foundation as Sandbox Project - https://www.businesswire.com/news/home/20200826005093/en/Rancher-Labs%E2%80%99-K3s-Joins-Cloud-Native-Computing

Open Network Automation Platform (ONAP)

Open Network Automation Platform (ONAP) project addresses the rising need for a common automation platform for telecommunication, cable, and cloud service providers and their solution providers that enables the automation of different lifecycle processes, to deliver differentiated network services on demand, profitably and competitively, while leveraging existing investments. It is an open source software platform that delivers robust capabilities for the design, creation, orchestration, monitoring, and life cycle management of Network Function Virtualization (NFV) environments, as well as Software-Defined Networks (SDN).

Network Functions Virtualization (NFV) allows network operators to reduce their dependence on single-purpose appliances by taking functions that were previously built into hardware and implementing them in software that runs on industry-standard servers, network, and storage platforms. Beyond reducing network operators’ dependency on dedicated hardware, leveraging NFV enables more programmability in the network and greatly reduces the complexity and time-to-market associated with introducing new services.

Network Function Virtualization(NFV) is a way to reduce cost and accelerate service deployment for network operators by decoupling functions like a firewall or encryption from dedicated hardware and moving them to virtual servers. Instead of installing expensive proprietary hardware, service providers can purchase inexpensive switches, storage and servers to run virtual machines that perform network functions. This collapses multiple functions into a single physical server, reducing costs and minimizing truck rolls. If a customer wants to add a new network function, the service provider can simply spin up a new virtual machine to perform that function. For example, instead of deploying a new hardware appliance across the network to enable network encryption, encryption software can be deployed on a standardized server or switch already in the network.

Software Defined Networking(SDN) technology is an approach to network management that enables dynamic, programmatically efficient network configuration in order to improve network performance and monitoring, making it more like cloud computing than traditional network management.

SDN vs NFV:

Network Functions Virtualization is highly complementary to Software-Defined Networking (SDN) but not dependent on it (or vice-versa). Network Functions Virtualization can be implemented without an SDN being required, although the two concepts and solutions can be combined and potentially greater value accrued.

Network Functions Virtualization goals can be achieved using non-SDN mechanisms, relying on the techniques currently in use in many data centers. But approaches relying on the separation of the control and data forwarding planes as proposed by SDN can enhance performance, simplify compatibility with existing deployments, and facilitate operation and maintenance procedures. NFV is able to support SDN by providing the infrastructure upon which the SDN software can be run. Furthermore, Network Functions Virtualization aligns closely with the SDN objectives to use commodity servers and switches.

ref:

ONAP - https://www.onap.org/

ONAP wiki - https://wiki.onap.org/

ONAP Glossary(NFV, SDN resources) - https://wiki.onap.org/display/DW/Glossary

ONAP Projects - https://wiki.onap.org/display/DW/ONAP+Projects

The Edge Multi Cloud Orchestrator(EMCO) Architecture & Design - https://wiki.onap.org/pages/viewpage.action?pageId=84668166

ONAP github source code - https://github.com/onap

ONAP multicloud-k8s github source code - https://github.com/onap/multicloud-k8s

ONAP gerrit - https://gerrit.onap.org/r/q/status:open

ONAP SDN - https://wiki.onap.org/display/DW/SDN-R

NFV(Network Function Virtualization) - https://en.wikipedia.org/wiki/Network_function_virtualization

ETSI NFV -

https://www.etsi.org/technologies/nfv

https://www.etsi.org/technologies/689-network-functions-virtualisation

OPNFV - https://www.opnfv.org/

ONAP documentation - https://docs.onap.org/en/frankfurt/

ONAP overview - https://docs.onap.org/en/frankfurt/guides/overview/overview.html

ONAP v2 High level Architecture - https://wiki.onap.org/download/attachments/1015842/arch3_207.png?version=1&modificationDate=1486486468000&api=v2

Communications Service Provider(CoSP) aka 5g Cloud -
https://www.intel.sg/content/dam/www/public/us/en/documents/white-papers/cosp-cloud-white-paper.pdf

https://blog.equinix.com/blog/2018/07/17/the-role-of-5g-networking-and-cloud/

NFV Microservices - https://blog.mellanox.com/2017/06/the-ideal-network-for-containers-and-nfv-microservices/

Cloud Native Edge App & NFV Stack(Srinivasa Addepalli) - https://events19.linuxfoundation.org/wp-content/uploads/2018/07/ONS2019_Cloud_Native_NFV.pdf

Misc =>

https://www.cisco.com/c/en/us/solutions/software-defined-networking/sdn-vs-nfv.html

https://www.blueplanet.com/resources/What-is-NFV-prx.html

https://wiki.opnfv.org/display/PROJ/OPNFV-ONAP

https://www.onap.org/tag/opnfv

https://www.opnfv.org/blog/2019/03/07/what-i-learned-at-the-onap-opnfv-event-in-paris-saclay

Open source data collector for Unified Logging - Fluentd

Fluentd is an open source data collector for unified logging layer. It allows you to unify data collection and consumption for a better use and understanding of data.

Fluentd decouples data sources from backend systems by providing a unified logging layer in between. It is Apache 2.0 Licensed, fully open source software. Fluentd treats logs as JSON, a popular machine-readable format. It is written primarily in C with a thin-Ruby wrapper that gives users flexibility.

Fluentd is an open source log management tool supported by the CNCF that unifies your data collection in a language- and platform-agnostic manner. It brings together data from your databases, system logs, and application events, filters out the noise, and then structures that data so it can be easily fed out to multiple destinations. Through its flexible plugin architecture, Fluentd works with hundreds of different services, from commercial products like Splunk to open source tools like ElasticSearch or MongoDB. Prized for microservices architecture, Fluentd is also an excellent choice for legacy and monolithic applications. Its reduced footprint sibling Fluent Bit is even applicable for the Internet of Things.