Tech Kaizen: 2020

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.

ref:

Fluentd - https://www.fluentd.org/

Fluentd overview - https://docs.fluentd.org/quickstart

Fluentd github - https://github.com/fluent/fluentd

Fluentd community - https://www.fluentd.org/community

Fluentd wiki - https://en.wikipedia.org/wiki/Fluentd

Fluentd as part of CNCF -

https://landscape.cncf.io/selected=fluentd

https://epsagon.com/tools/cncf-tools-overview-fluentd-unified-logging-layer/

Aggregating Application Logs from Kubernetes Clusters using Fluentd to Log Intelligence -

https://medium.com/@bahubalishetti/aggregating-application-logs-from-kubernetes-clusters-using-fluentd-to-log-intelligence-91da5f536692

https://medium.com/kubernetes-tutorials/cluster-level-logging-in-kubernetes-with-fluentd-e59aa2b6093a

Analyzing logs in real time using Fluentd and BigQuery - https://cloud.google.com/solutions/real-time/fluentd-bigquery

Open source Identity and Access Management(IAM) - Keycloak

Single sign-on (SSO) is a property of Identity and Access Management (IAM) that enables users to securely authenticate with multiple applications and websites by logging in only once with just one set of credentials (username and password). With SSO, the application or website that the user is trying to access relies on a trusted third party to verify that users are who they say they are. It is often accomplished by using the Lightweight Directory Access Protocol (LDAP) and stored LDAP databases on (directory) servers.

Keycloak is an open source software product to allow single sign-on(SSO) with Identity and Access Management(IAM) aimed at modern applications and services. Keycloak supports both SAML and Auth2.0 protocols. Keycloak holds the Apache open source license.

Keycloak supports OpenID Connect and SAML (Security Assertion Markup Language) protocols. OpenId Connect is known to be an extension of the OAuth2 protocol also it’s a framework for building authorization protocols.

====

Authentication => The process of verifying who a user is

Authorization => The process of verifying what they have access to

SAML (Security Assertion Mark-up Language) => An umbrella standard that covers federation, identity management and single sign-on (SSO)

OAuth (Open Authorization) => A standard for authorization of resources. OAuth 2.0 is a framework that controls authorization to a protected resource such as an application or a set of files

OpenID Connect => A standard for federated authentication. OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol, which allows computing clients to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner

====

OpenSource Single Sign-on(SSO) products:

1. Keycloak - https://www.keycloak.org/, https://www.keycloak.org/getting-started/getting-started-kube

2. Shibboleth - https://www.shibboleth.net/, https://www.internet2.edu/products-services/trust-identity/shibboleth/

3. Univention Corporate Server - https://www.univention.com/

4. WSO2 Identity Server - https://wso2.com/identity-and-access-management/

ref:

wiki - https://en.wikipedia.org/wiki/Keycloak

OpenSource Single Sign-On(SSO) - https://medium.com/faun/opensource-single-sign-on-sso-e52d39e1927

Difference Between OAuth, OpenID Connect, and SAML - https://www.okta.com/identity-101/whats-the-difference-between-oauth-openid-connect-and-saml/

Choosing an SSO Strategy: SAML vs OAuth2 - https://www.mutuallyhuman.com/blog/choosing-an-sso-strategy-saml-vs-oauth2/

Adding authentication to your Kubernetes Web applications with Keycloak =>

1. https://www.openshift.com/blog/adding-authentication-to-your-kubernetes-web-applications-with-keycloak

    2. https://medium.com/stakater/proxy-injector-enabling-sso-with-keycloak-on-kubernetes-a1012c3d9f8d

    3. https://thenewstack.io/kubernetes-single-sign-one-less-identity/

    4. https://www.keycloak.org/getting-started/getting-started-kube

    5. https://blog.codecentric.de/en/2019/05/configuring-kubernetes-login-keycloak/

kubernetes ingress controller as Reverse proxy for SSL/TLS Termination

TLS Termination((or SSL termination, or SSL offloading, or Reverse TLS) proxy intercepts and decrypts incoming TLS traffic, such as HTTPS or IMAPS, before it is forwarded to another server. It is a proxy server that is used by an institution to handle incoming TLS connections, decrypting the TLS and passing on the unencrypted request to the institution's other servers (it is assumed that the institution's own network is secure so the user's session data does not need to be encrypted on that part of the link).

TLS termination proxies are used to reduce the load on the main servers by offloading the cryptographic processing to another machine, and to support servers that do not support SSL.

Kubernetes Ingress is an API object that manages external access to the services in a cluster, typically HTTP. Ingress may provide load balancing, SSL termination and name-based virtual hosting. An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name based virtual hosting. An Ingress controller is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic.

An Ingress does not expose arbitrary ports or protocols. Exposing services other than HTTP and HTTPS to the internet typically uses a service of type Service.Type=NodePort or Service.Type=LoadBalancer.

You must have an ingress controller to satisfy an Ingress. Only creating an Ingress resource has no effect.You may need to deploy an Ingress controller such as ingress-nginx.

Nginx Ingress Controller:

An Ingress object routes traffic into your cluster to the correct application. By default, an ingress enables a Google Cloud Load Balancer. These are some badass, globally available load balancers that can handle an outrageous amount of traffic. You probably don’t need that for most applications, especially development environments

The Nginx ingress controller is a substitute. Its an application that runs in your cluster and handles routing and load balancing traffic. It’s simple to add an nginx ingress controller; apply the files in this repository

kubectl apply -f nginx-ingress-controller/Copy

It will take a moment for nginx-ingress-lb to acquire an IP address. During that time, running the command kubectl get services -n kube-system will show something like the following:

NAME                   CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
default-http-backend   10.55.241.224   <nodes>       80:32516/TCP                 11d
heapster               10.55.255.208   <none>        80/TCP                       11d
kube-dns               10.55.240.11    <none>        53/UDP,53/TCP                11d
kubernetes-dashboard   10.55.240.50    <none>        80/TCP                       11d
nginx-ingress-lb       10.55.249.186   <pending>     80:32005/TCP,443:31623/TCP   6sCopy

Where nginx-ingress-lb‘s EXTERNAL-IP is <pending>. Once that <pending> flips to an IP address, note the IP address. Navigate to VPC Network->External IP adresses in the Google Cloud console. Locate the IP address in that list and change it’s type from Ephemeral to Static. (You’ll be prompted for a name which can be whatever you like.)

====

Install Nginx Ingress Controller to your cluster using HELM:

Install nginx ingress controller using HELM => helm install nginx-ingress stable/nginx-ingress --set controller.publishService.enabled=true

Check whether service got installed => kubectl get services -o wide -w nginx-ingress-controller

====

Install nginx ingress controller & ingress resource on Bare-metal Using NodePort:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.35.0/deploy/static/provider/baremetal/deploy.yaml

Verify installation:
kubectl get pods -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx --watch

Once the ingress controller pods are running, you can cancel the command typing Ctrl+C.

Now, you are ready to create your first ingress =>

Detect installed version:
To detect which version of the ingress controller is running, exec into the pod and run nginx-ingress-controller version command.

POD_NAMESPACE=ingress-nginx
POD_NAME=$(kubectl get pods -n $POD_NAMESPACE -l app.kubernetes.io/name=ingress-nginx --field-selector=status.phase=Running -o jsonpath='{.items[0].metadata.name}')

kubectl exec -it $POD_NAME -n $POD_NAMESPACE -- /nginx-ingress-controller --version

Using Helm:
NGINX Ingress controller can be installed via Helm using the chart from the project repository.

To install the chart with the release name ingress-nginx:
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm install my-release ingress-nginx/ingress-nginx

Detect installed version:

POD_NAME=$(kubectl get pods -l app.kubernetes.io/name=ingress-nginx -o jsonpath='{.items[0].metadata.name}')
kubectl exec -it $POD_NAME -- /nginx-ingress-controller --version

====

ref:

Wiki - https://en.wikipedia.org/wiki/TLS_termination_proxy

SSL/TLS Termination Reverse Proxy - https://docs.nginx.com/nginx/admin-guide/security-controls/terminating-ssl-http/

Kubernetes TLS Termination =>

1. https://www.magalix.com/blog/implemeting-a-reverse-proxy-server-in-kubernetes-using-the-sidecar-pattern

2. https://www.getambassador.io/docs/latest/howtos/tls-termination/

3. https://kubernetes.github.io/ingress-nginx/examples/tls-termination/

4. https://kubernetes-on-aws.readthedocs.io/en/latest/user-guide/tls-termination.html

Kubernetes ingress =>

1. https://kubernetes.io/docs/concepts/services-networking/ingress/

2. https://github.com/kylemcc/kube-nginx-proxy