Changes for page API Gateway Architecture

Summary

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

Details

Page properties

Title

...	...	@@ -1,1 +1,1 @@
1		-API Gateway Architecture
	1	+advanced-solution-architecture-change-memory-runtime-linux

Content

...	...	@@ -1,76 +1,73 @@
1	1	{{container}}{{container layoutStyle="columns"}}(((
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
	2	+This microlearning will focus on the aspects of eMagiz Cloud and sizing of the Cloud
3	3
4		-Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
	4	+Should you have any questions, please contact academy@emagiz.com.
5	5
	6	+* Last update: October 21st, 2021
	7	+* Required reading time: 5 minutes
	8	+
6	6	== 1. Prerequisites ==
7	7	* Intermediate knowledge of the eMagiz platform
8		-* Good working experience in the Design phase Architecture and Deploy Architecture
9		-* Created several API gateway integrations
	11	+* Good working experience in the Design & Deploy architecture aspects
10	10
11	11	== 2. Key concepts ==
	14	+The eMagiz Cloud is the set of services and machines that make up together the engine in which the integrations are made active. Please refer to the eMagiz Cloud Fundamentals to learn about that Cloud infrastructure.
12	12
13		-* Single lane -> Single runtime per types
14		-* Double lane -> Two or more runtime per type to handle failover setups
15	15
16		-== 3. Architecture considerations ==
17	17
18		-=== 3.1 Architecture components API Gateway ===
	18	+== 3. eMagiz Cloud sizing ==
19	19
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.
	20	+eMagiz provides insight into the required sizing of the machines and runtimes in the Design architecture. Objective is to configure the proper size of the Cloud machines so that the designed architecture can actually be effectuated.
21	21
22		-[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-apigw-architecture-1.png]]
	22	+=== 3.1 Cloud approval ===
	23	+The eMagiz team will provide approval on what type of Cloud your model has access to. In the figure below you can see the first column where the number of machines for a specific T*shirt size are allowed. The Cloud approval can be done by your eMagiz partner and is based on the licensed eMagiz Cloud. Once in the edit modus of the Design architecture, you can assign the available Cloud machine to a specific Core or Connector machine in the architecture.
23	23
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.
	25	+[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-consequence-size-cloud-1.png]]
31	31
32		-=== 3.2 Single lane Cloud setup ===
	27	+=== 3.2 Cloud t-shirt sizing ===
	28	+eMagiz provides the following sizing for the Cloud slots. The memory is mentioned below as that is the key driver for upgrading to bigger sizing.
33	33
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.
	30	+1. S size **> 2Gb memory per machine
	31	+2. M size **> 4Gb memory per machine
	32	+3. L size **> 8Gb memory per machine
	33	+4. XL size **> 16Gb memory per machine
	34	+
	35	+=== 3.3 Cloud sizing advice ===
35	35
36		-* Core 01 -> holds the JMS Server and the messaging process container
37		-* Connnector 01 -> holds the API Gateway container and the messaging runtimes
	37	+In the [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-design-understanding-design-architecture-basic.WebHome||target="blank"]] you can see how to the current machines can be reviewed for available memory.
38	38
39		-[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-apigw-architecture-2.png]]
	39	+=== 3.4 Impact of Cloud sizing ===
40	40
41		-=== 3.3 Double lane Cloud setup ===
	41	+The actual assigned machine size will be implemented in the Deploy architecture. In case your total runtime and machines are consuming more than the available memory of that specific size, the runtimes will not properly load and become disfunctional. To determine overcommitted cloud machines, use the following calculation mechnanism
42	42
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.
	43	+1. Count 762 Mb overhead for the machine
	44	+2. Count 100 Mb per runtime on the machine
	45	+3. Count the tables for the runtime head and non-heap memory according to NL. See this [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Expert Level.Solution Architecture.expert-solution-architecture-determining-needed-memory.WebHome||target="blank"]] for more information
44	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
	47	+This count is also handy when verifying the actual assigned values in Deploy Architecture.
49	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.
	49	+=== 3.5 Managing sizing of Event topics ===
51	51
52		-[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-apigw-architecture-3.png]]
	51	+In the Design architecture you can manage your sizing of Event Streaming topics. eMagiz sees the topics as part of the Cloud infrastructure. Right clicking the topic storage in Design Architecture, would lead to the following screen - see fiugure below. Options available are:
53	53
54		-=== 3.4 Hybrid Cloud setup ===
	53	+1. Change sizing values of topics (retention size).
	54	+2. Exclude topics * which effectively means that these no longer count towards the configured size and if effectuated in the Deploy will be deleted. This feature is handy to use in the lifecycle of topics from test to acceptance to production. Topics in test can be excluded in case the topic is already in production.
55	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:
	56	+[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-consequence-size-cloud-2.png]]
57	57
58		-[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-apigw-architecture-4.png]]
59	59
60		-=== 3.5 Memory ===
61	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	63
64	64	== 4. Assignment ==
65	65
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"]].
	63	+Please experiment with the options in eMagiz Design architecture to understand the above points.
67	67
	65	+
68	68	== 5. Key takeaways ==
	67	+Part of the eMagiz platform is the Cloud which has specific upper limits for sizing. Understanding these helps to understand the impact of the designed architecture and to decide to influence these upper limits by expanding the sizing to a higher range.
69	69
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
73	73
	70	+
74	74	== 6. Suggested Additional Readings ==
75	75
76	76	There are no suggested additional readings on this topic