CODEX
Network Software Architecture — Emerging Concepts and Approaches
Cloud-Native Application
This is an approach to have your application separated as micro-services each of them with dependencies is packaged into containers running on a certain container orchestration system. In details, there are different aspects that need to take into account:
- Microservice: Your application is now constructed by the collaboration of a collection of services (which are micro-services from architecture perspective). There would be discussions inside your team about defining services, the strategy of implementing them, where to deploy them, blah blah. Some questions you might have from the beginning, in the design phase are, “hey, this can be a service but since its function is simple now, can we put it together with the service XYZ and separating it later?”, or “should we use the same DB for all the services or each one should have its own DB?”, or “how about the log, should we save all the logs to our DB or only push them to the ABC system?” (usually this is the system that other team is managing, say, to tracking the issue, to evaluate if your application is well coded, no bug or 10000 bugs), and so on. Btw, talking about microservice, we need to mention APIs, for example, format of APIs, authentication, API version.
- Monitoring (telemetry and reporting): A service failure can bring your whole application down. Hard to believe, what if the gateway which is the entry point for all the request from your end-users is down? :) We need a way to have services in our system notifying us if there are any abnormal things. Logging is the first thing you have in mind. We also have other things, of course based on log data, for instance, from Fluentd, LogStash, Kafka (yes, Apache Kafka), to CloudWatch, Prometheus and Grafana. I am willing to call you a senior if you can deploy a “Hello World” example as a micro-service on Kubernetes together with all the mentioned tools.
- Resiliency: Have you heard about Chaos Engineering and Chaos Monkey? While it is impossible to know when/how/where a service can fail, all the services should be able to handle if their input from other services is not what it expects, i.e. wrong format, late, request timeout.
Network Automation
Let’s say you have a network running well now, which could have some issues one day. So network automation is a process of keeping your network running well in the future without your touch. I summarize all the aspects of the implementation of Network Automation as following:
- Intent-based Networking: From architect perspective, if you have no idea of low-level network devices’ commands, then IBN comes into the picture. In detail, you only need to tell what you want (your intent) and there would be some tools to make that happens. Those tools should understand your ideas and have the capability to translate your intention to the syntax of network devices.
- API and Data Model: From engineer perspective, while the former provide you with a means to transmit your intent or receive what you expect from your intent, the latter is the way via which you represent your intent or expected result. In other words, it requires to understand network devices and making yourself understandable by the devices, via APIs, i.e. REST, RESTCONF, NETCONF, and data models, i.e. YANG.
- Network Monitoring: This is to answer the question how to know if there is something wrong/wright to your network. You need to be able to monitor a network using SNMP (for IP network). You can hear a lot about SNMP when reading the related books, but note that there are a variety of custom protocols doing the same task. Even not only IP networks, but there is also a need of monitoring optical networks as well.
- Data Analytics: Able to analyzing collected data to provide useful input for the intention making process. Here, Elastic Stack (ElasticSearch, Kibana, LogStash) comes to the picture :)
- Automation Framework: Ansible seems to be the most famous infrastructure automation framework. You may also hear about other tools like Chef, Puppet, SaltStack.
- Cloud-Native: Developing network services to abstract the network from a higher-level view so as to realize the Network Automation process and deploying them in a cloud-native approach.
Serverless Computing
Let’s say you have an app A (a website) composed of different features A1 (MySQL server), A2 (load balancer), A3 (firewall), A4 (HTTP server), you need to install all of them, either in the same machine (physical, virtual, container, whatever) or in a distributed manner. With serverless computing, you only need to register those functions which are deployed somewhere that you don’t need to care about (but pay) :).
Again, here are some topics that you may need to be aware of to answer any of the detailed questions:
- Event-driven Computation, Function as a Service (you can see the key value of micro-service architecture now — a system with a number of functions for others to use)
- Since your grandmom is a curious guy, she may need to know how the provider manages to provide you such an approach, then here is an illustration.
Service Mesh
In the micro-service architecture, as the number of services increase, a composite application needs to face the complicated interactions between them, in terms of monitoring service health, handling failure, authentication, and more. Service mesh comes as a solution to have an application infrastructure layer that handles the inter-service communication, for instance, that layer can do the health monitor instead of your application or the micro-service themselves.
To implement a service mesh, you can deploy a proxy alongside your services. This is also known as the sidecar pattern. Envoy and Istio are the 2 most popular platforms for this purpose.
