cancel
Showing results for 
Search instead for 
Did you mean: 
PingXiong
F5 Employee
F5 Employee

1   Introduction

When we discuss the modernization of applications, Kubernetes will probably come out first. When discussing the delivery of modern applications, you probably think of deploying ingress controller or servicemesh. Through the survey of enterprises and customer visits, we learned that the situation of most enterprises is much more complex. They usually need to operate a variety of application architectures at the same time. Even if they use the same microservices architecture, there are different implementation and deployment modes; Even if Kubernetes is also adopted, it is possible to adopt different application delivery methods. For enterprises, how to successfully deliver these applications is a huge challenge.

  • How to dynamically deliver microservices architecture applications?
  • What if the microservice gateway expands the service node?
  • Can microservices architecture applications take advantage of Kubernetes' high flexibility and high availability without re-architecting?
  • How can microservices applications invoke legacy applications like accessing internal services?

Based on the above thinking, we have developed a group of plug-ins for BIG-IP with the support of F5's InnovateF5 Innovation Incubation Platform to help enterprises address above challenges and connect modern applications with legacy applications. Thanks to all members of the bridge2modernapp InnovateF5 project for their contributions, @ChunZheng_YU@Hua_Guo@Weitao_TANG@JayLiang946, and @YZhang .

InnovateF5 is an employee innovation platform sponsored by the CTO Office of F5, which provides employees with various resources to turn ideas into reality. Many well-known products in the industry are produced in a similar way, such as Java.

2  Enterprises' applications portfolio

Back to basics, let's look closely at the application assets of enterprises. The digital transformation of enterprises needs modern applications. With the continuous deepening of enterprise digital transformation, especially the impact of the COVID-19, it has further promoted the expansion of enterprise digital transformation from customer experience related systems to internal business systems. The modernization of application system has become an important technical means to achieve this goal.

Application modernization is a long-term process, and the coexistence of multiple application architectures is normal. The modernization of applications does not mean that all application systems need to be torn down or rewritten to realize the modernization of existing business systems. In fact, the coexistence of multiple application architectures will become the norm.

Figure 1 Application Architectural Proliferation - F5 State of Application Strategy 2021Figure 1 Application Architectural Proliferation - F5 State of Application Strategy 2021

As can be seen from the above figure, almost 90% of users use more than two application architectures at the same time, and nearly 50% of users use five application architectures.

Figure 2 Application Modernization Methods - F5 State of Application Strategy 2021Figure 2 Application Modernization Methods - F5 State of Application Strategy 2021

Rewriting code is a way to realize application modernization, but it is not the most important form. On the contrary, it is widely adopted to add a layer of API or add some components of modern applications to existing applications. Therefore, in the process of digital transformation of most enterprises, the application deployment form we see may be the following hybrid form of multi architecture coexistence.

Figure 3 Hybrid Application ArchitectureFigure 3 Hybrid Application Architecture

3   Microservices architecture

Microservice is not a new topic. There are many books, articles and blogs in the industry that have described it in detail. If necessary, you can also visit the website https://microservices.io to get a more comprehensive understanding. This article is just a brief review of some key points of service discovery and service registration.

Figure 4 Client-Side vs Server-Side discovery - https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/Figure 4 Client-Side vs Server-Side discovery - https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/

3.1 Service Discovery: Client-side discovery vs Server-side discovery.

One is client-side service discovery. The client directly communicates with the service registry to obtain information about other services. The other is server-side service discovery. Instead of directly discovering each service endpoint, the client accesses the service through the load balancer or gateway, which isolates the complexity of the server.

Both models are widely used. For example, in the public cloud, many use the server-side discovery mechanism.

Figure 5 Self-registration vs 3rd-party registration - https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/Figure 5 Self-registration vs 3rd-party registration - https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/

3.2 Service Registration: Self-Registration vs 3rd party registration

There are also two main forms of service registration. The first is self-registration, that is, after the service is started, actively register yourself in the service registry. The other is to register through a third party, and usually carry out health monitoring on the service.

3.3 Service registry

The service registry is another very important role in the microservice architecture. It is used to store the relevant information and status of services in the application system. It is usually deployed in a distributed architecture to achieve high availability. It ensures the consistency of data through a consensus algorithm, and usually provides API or client access.

Table 1 Service Registry

 

ZooKeeper

Eureka

Consul

etcd

Nacos

Cluster

Leader/Follower

Non leader /Follower

Leader/Follower

Leader/Follower

Non leader /Follower

consensus algorithm

ZAB

~

Raft

Raft

Distro + Raft

CAP model

CP

AP

CP

CP

AP + CP

Interface

TCP

HTTP

HTTP/DNS

HTTP

HTTP/DNS

Typical App

Kafka

SpringCloud

many

Kubernetes

SOFAstack

 

3.4 Enable service discovery and registration for BIG-IP

3.4.1 MSDA and MSRA

Based on our understanding of the above information, we believe that giving BIG-IP the ability to discover and register services can bring value to the digital transformation of enterprises, support the modernization of applications, improve the adaptability and automation of enterprise application systems, reduce friction, and improve productivity.

Therefore, we have submitted an InnovateF5 project, which aims to endow BIG-IP with the ability of service discovery and service registration and connect traditional and modern applications of enterprises.

Table 2 Microservice Agents for BIG-IP

 

MSDA (Microservice Discovery Agent)

MSRA (MicroService Registration Agent)

Implementation

Based on iApps LX(node.js),provide WebUI and API

Feature

Server-Side discovery.

Discover services from service registry, inject BIG-IP.

1st stage target on pool only.

3rd party registration.

Monitor Virtual servers in F5, register into service registry.

Service Registry to support

Zookeeper

Nacos

Etcd

Eureka

Consul

 

3.4.2 Use cases

There are 3 major use cases for MSDA and MSRA:

  • Expose microservice applications to external user or legacy applications. The microservice app can be:
    1. Distributed applications, without development framework. It just leverages distributed architecture and service registry to build their own application.
    2. Microservice applications based on development frameworks, such as Dubbo, SpringCloud, SOFAStack.
    3. Microservice applications deployed in K8S, just use k8s as a resilience platform, and use pod as VM.
    4. Kubernetes native applications, leverage k8s ingress or service to expose service.
  • Service Proxy between microservice applications. Different applications may use their own independent service registry. MSRA can be used to register with each other, and BIG-IP can be used as a bridge for mutual access.
  • Expose legacy applications to microservice applications by register them into service registry. Microservice applications do not need to care about the deployment location of traditional applications and service exposure information. They access external services just like internal services.

Figure 6 Use casesFigure 6 Use cases

3.4.3 User Experience

The user interface is very important for the user experience. MSDA and MSRA are developed based on IAPPS LX, so we can leverage the native user interface of BIG-IP. Includes WebUI and restful API.

WebUI

  1. Get the rpm package of the template.
  2. Import the rpm package into BIG-IP. iApps >> Package Management LX>> import
  3. Modify the template if you want. iApps >> Templates >> Template LX
  4. Create application through the template. iApps >> Application Services >> Applications LX.

Figure 7 WebUIFigure 7 WebUI

Restful API

  1. Get the rpm package of the template.
  2. Import the rpm package into BIG-IP. iApps >> Package Management LX>> import
  3. Copy the template you want and save it as a json file. iApps >> Templates >> Template LX
  4. Follow the steps to create applications through API: Clouddocs iApps LX operation guide.

Figure 8 Restful APIFigure 8 Restful API

4 Deliver modern App with BIG-IP

Figure 9 Deliver Modern App with BIG-IPFigure 9 Deliver Modern App with BIG-IP

Through MSDA and MSRA, we can use BIG-IP as the core facility for application delivery, deliver traditional applications as usual, and build a bridge between modern applications and traditional applications, so that they can be quickly and automatically deployed without friction and improve efficiency.

4.1 Test it Out

Welcome to use F5 BIG-IP to deliver modern applications and serve as a bridge between modern applications and legacy applications.

 

Table 3 Repositories

Service Registry

Agent Name

Repository

Kubernetes

MSDA-K8S

https://github.com/f5devcentral/msda-kubernetes

Etcd

 

MSDA-etcd

https://github.com/f5devcentral/msda-etcd

MSDA-etcdv3

https://github.com/f5devcentral/msda-etcd

Nacos

 

MSDA-nacos

https://github.com/f5devcentral/msda-nacos

MSRA-nacos

https://github.com/f5devcentral/msra-nacos

Zookeeper

MSDA-ZK

https://github.com/f5devcentral/msda-zookeeper

Consul

 

MSDA-consul

https://github.com/f5devcentral/msda-consul

MSRA-consul

https://github.com/f5devcentral/msra-consul

Eureka

 

MSDA-eureka

https://github.com/f5devcentral/msda-eureka

MSRA-eureka

https://github.com/f5devcentral/msra-eureka

 

Disclaimer: These iAppsLX RPM packages are not officially supported by F5 Inc, any issue or feedback, please raise an issue to the GitHub repository, or send an email to msda@f5.com .

5 Reference

For more information cited in this article, please refer to:

Comments
PingXiong
F5 Employee
F5 Employee

If you want to use RPMs directly rather than build from the source code, please download RPM packages from it's upstream repo https://github.com/ChinaModernAppGroup.

Have fun.

Version history
Last update:
‎14-Jul-2022 09:26
Updated by: