Changes for page API Gateway Architecture

Summary

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

Details

Page properties

Title

...	...	@@ -1,1 +1,1 @@
1		-Consequences of cloud size changes and cloud approval
	1	+advanced-solution-architecture-consequence-size-cloud

Content

...	...	@@ -1,70 +1,49 @@
1	1	{{container}}{{container layoutStyle="columns"}}(((
2		-This microlearning will focus on the aspects of eMagiz Cloud and sizing of the Cloud
	2	+This microlearning will focus on some considerations for putting the eMagiz runtime at the right location in the architecture.
3	3
4	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
	6	+* Last update: October 20th, 2021
	7	+* Required reading time: 10 minutes
8	8
9	9	== 1. Prerequisites ==
10	10	* Intermediate knowledge of the eMagiz platform
11		-* Good working experience in the Design & Deploy architecture aspects
	11	+* Good working experience in the Design and Deploy Architecture phase.
12	12
13	13	== 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.
	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
16	16
17	17
18		-== 3. eMagiz Cloud sizing ==
	18	+== 3. Specific eMagiz runtime considerations ==
19	19
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.
	20	+=== 3.1 Messaging pattern runtimes ===
21	21
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.
	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.
24	24
25		-[[image:Main.Images.Microlearning.WebHome@advanced*solution*architecture*consequence*size*cloud*1.png]]
	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 ===
26	26
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	+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)
29	29
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	+=== 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.
36	36
37		-In the [microlearning](crashcourse*platform*design*understanding*design*architecture*basic.md) you can see how to the current machines can be reviewed for available memory.
38	38
39		-=== 3.4 Impact of Cloud sizing ===
40	40
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		-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](expert*solution*architecture*determining*needed*memory.md) for more information
46		-
47		-This count is also handy when verifying the actual assigned values in Deploy Architecture.
48		-
49		-=== 3.5 Managing sizing of Event topics ===
50		-
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:
52		-
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		-
56		-[[image:Main.Images.Microlearning.WebHome@advanced*solution*architecture*consequence*size*cloud*2.png]]
57		-
58		-
59		-
60		-
61	61	== 4. Assignment ==
62	62
63		-Please experiment with the options in eMagiz Design architecture to understand the above points.
	43	+There is no specific assignment as this is more theoretical microlearning.
64	64
65		-
66	66	== 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.
	46	+Take into account the key considerations for each case to ensure the runtime is placed on the right location.
68	68
69	69
70	70