Changes for page API Gateway Architecture

Summary

• Page properties (2 modified, 0 added, 0 removed)

Details

Page properties

Title

...	...	@@ -1,1 +1,1 @@
1		-advanced-solution-architecture-consequence-size-cloud
	1	+API Gateway Architecture

Content

...	...	@@ -1,52 +1,76 @@
1	1	{{container}}{{container layoutStyle="columns"}}(((
2		-This microlearning will focus on some considerations for putting the eMagiz runtime at the right location in the architecture.
	2	+This micro-learning will focus on describing the general architecture of the API Gateway. After this microlearning, the background of the API GW architecture should be clear
3	3
4		-Should you have any questions, please contact academy@emagiz.com.
	4	+Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
5	5
6		-* Last update: October 20th, 2021
7		-* Required reading time: 10 minutes
8		-
9	9	== 1. Prerequisites ==
10	10	* Intermediate knowledge of the eMagiz platform
11		-* Good working experience in the Design and Deploy Architecture phase.
	8	+* Good working experience in the Design phase Architecture and Deploy Architecture
	9	+* Created several API gateway integrations
12	12
13	13	== 2. Key concepts ==
14		-In the various microlearnings until the intermediate level, we have explained the eMagiz runtime (https://emagiz.github.io/docs/microlearning/crashcourse*platform*deploy*install*local*connector). In short, it is the process that can make the flow components operational and execute the designated tasks of that flow. Please refer to these microlearnings for further information
15	15
	13	+* Single lane -> Single runtime per types
	14	+* Double lane -> Two or more runtime per type to handle failover setups
16	16
	16	+== 3. Architecture considerations ==
17	17
18		-== 3. Specific eMagiz runtime considerations ==
	18	+=== 3.1 Architecture components API Gateway ===
19	19
20		-=== 3.1 Messaging pattern runtimes ===
	20	+The following picture displays a general architecture of the API Gateway. This picture has been taken from the eMagiz Design Architecture section as that illustrates the below key points.
21	21
22		-For Messaging specific patterns the runtime should be placed in such a way that there is connectivity between that runtime and the sending/receiving system. The system might be located in a Cloud service or Cloud VPC that eMagiz clients are hosting. Or are located on*premises of the client. Here are the options and advice for putting the runtime.
	22	+[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-apigw-architecture-1.png]]
23	23
24		-1. Sender or Receiver system is located in a public or private Cloud
25		- * Put the Runtime on a Cloud Connector machine and ensure to use the connectivity options provided in eMagiz
26		-
27		-2. Sender or Receiver system is located in a DMZ section of the client infrastructure
28		- * Put the runtime inside the same DMZ zone to keep the runtime as close to the system as possible
29		- * Ensure the management of the runtime is something workable for the client. Consider the updates that may occur as well as the fact that the runtime can no longer be managed by the eMagiz Portal
30		-
31		-=== 3.2 API Gateway pattern runtimes ===
	24	+Key notes
	25	+1. Gateway runtime
	26	+The Gateway has a separate runtime where the associated gateway flows are deployed in. The exit gates and all entry flow are the typical flow types present in this runtime, next to the usual infrastructure flow
	27	+2. Location runtime
	28	+The Gateway runtime is located in a Cloud machine, and is specifically put on the Connector machine. The Connector machine has the ability to allow incoming data (secured) traffic from outside the Virtual Private Cloud that each client has. The Core machine does not have this option due to security reasons. The eMagiz Cloud handles the proper and secure routing to the API gateway.
	29	+3. Gateway only runtime
	30	+These are system that act as application user of 1 or more operations made available in the API Gateway. In case the system is only connected in the Design phase as such an application user, than that system only acts as input for User Management. The system doesn't need to be deployed as a runtime on the Connector machine, and should therefore be placed on an excluded machine. In the picture above, Exact online is such a system.
32	32
33		-For these runtime the first choice is put all the Gateway Entry Flow and the Exit gates on the Cloud Connector machine. This way, the number of runtimes are kept to a minimum and there is full control over these runtime. In the exceptional case where the exit gate needs to connect to a system that is not accessible via the client firewalls, you can opt to put these exit gates only on a runtime that can be deployed on*premises. Please refer to the [microlearning around running part of the solution locally](advanced*api*management*running*part*of*your*api*gateway*solution*on*premise)
	32	+=== 3.2 Single lane Cloud setup ===
34	34
35		-=== 3.3 Event Streaming pattern runtimes ===
36		-In the case where Event processors are used in the Event Streaming solution designed, eMagiz provides a event streaming container (runtime). This runtime can only run in a Cloud-based machine, and only in the core machines of eMagiz. The key reason is that these Event Processors need to connect to the topics that are only available in the eMagiz Cloud and not accessible from outside the eMagiz VPC. Any runtime that is consuming or producing data with these topics needs to have the capability to access such topics.
	34	+Single lane setup in eMagiz means that all runtimes are provided once in the architecture diagram * there is no failover or clustered approach for the runtimes. For the API Gateway, this means that you have the following machines available. In this example, you have the messaging patterns components as well with the objective to see such cases as well.
37	37
	36	+* Core 01 -> holds the JMS Server and the messaging process container
	37	+* Connnector 01 -> holds the API Gateway container and the messaging runtimes
38	38
	39	+[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-apigw-architecture-2.png]]
39	39
	41	+=== 3.3 Double lane Cloud setup ===
40	40
	43	+Double lane setup in eMagiz means that all runtimes are provided at least twice in the architecture diagram * there is a failover for the JMS runtimes and gateway containers. For the API Gateway, this means that you have the following machines available. In this case you need to make sure that the flows are duplicated properly across the containers in Deploy * Containers. By default eMagiz will spread all flows over both gateway containers.
	44	+
	45	+* Core 01 -> holds the JMS Server and the 1st messaging process container
	46	+* Core 02 -> holds the backup JMS Server and the 2nd messaging process container
	47	+* Connnector 01 -> holds the 1st API Gateway container
	48	+* Connnector 02 -> holds the 2nd API Gateway container
	49	+
	50	+The choice to create a double lane API gateway is to be done where there is a requirement for very high performance around response times and throughput. Please contact eMagiz to discuss such options.
	51	+
	52	+[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-apigw-architecture-3.png]]
	53	+
	54	+=== 3.4 Hybrid Cloud setup ===
	55	+
	56	+In the [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Advanced Level.API Management.advanced-api-management-running-part-of-your-api-gateway-solution-on-premise.WebHome||target="blank"]] you can find the reasons and configuration for running the exit gates in on-premises runtimes. A view of such a architecture is displayed here:
	57	+
	58	+[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-apigw-architecture-4.png]]
	59	+
	60	+=== 3.5 Memory ===
	61	+
	62	+For now the memory requirements for API Gateway are the same as for Messaging flows. Please refer to the [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Expert Level.Solution Architecture.expert-solution-architecture-determining-needed-memory.WebHome||target="blank"]].
	63	+
41	41	== 4. Assignment ==
42	42
43		-There is no specific assignment as this is more theoretical microlearning.
	66	+There is no specific assignment for now. The correct use of the Design architecture is explained in this [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-design-understanding-design-architecture-basic.WebHome||target="blank"]].
44	44
45	45	== 5. Key takeaways ==
46		-Take into account the key considerations for each case to ensure the runtime is placed on the right location.
47	47
	70	+1. API Gateways can be part of a mixed landscape of Messaging, Event Streaming and API Gateways
	71	+2. A single lane setup is usually sufficient for most cases
	72	+3. Hybrid setups are possbible but please be sure the ask the right questions before implementing such
48	48
49		-
50	50	== 6. Suggested Additional Readings ==
51	51
52	52	There are no suggested additional readings on this topic