Skip to Content
Last modified by Waria on 2026/07/23 09:38
From version 21.1
edited by Waria
on 2026/07/23 09:33
Change comment: There is no comment for this version
To version 3.1
edited by Erik Bakker
on 2022/06/13 08:06
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Key differences Design & Deploy Architecture
1 +Consequences of cloud size changes and cloud approval
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.waria
1 +XWiki.ebakker
Content
... ... @@ -1,78 +1,79 @@
1 -{{container}}
2 -{{container layoutStyle="columns"}}
3 -(((
4 -In this microlearning, we’ll explore the differences between the Design Architecture and Deploy Architecture within eMagiz. While the Design Architecture is where integration models are initially structured and systems are assigned to either Cloud or on-premises machines, the Deploy Architecture is where these designs are brought to life. However, not all systems in the Design phase will appear in the Deploy phase due to their specific roles or configurations. Understanding these key differences will help you better manage and implement your integration architecture effectively.
1 +{{container}}{{container layoutStyle="columns"}}(((
2 +This microlearning will focus on the aspects of eMagiz Cloud and sizing of the Cloud
5 5  
6 -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.
7 7  
8 -== 1. Prerequisites ==
6 +* Last update: October 21st, 2021
7 +* Required reading time: 5 minutes
9 9  
9 +== 1. Prerequisites ==
10 10  * Intermediate knowledge of the eMagiz platform
11 11  * Good working experience in the Design & Deploy architecture aspects
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 14  
15 -The Design Architecture is the place where the architecture of the integration model is forged. It allows to place Systems to Cloud or On-premises connector machines so that hybrid cloud architectures are possible. The Deploy Architecture is the place where the Design architecture is effectuated. In case a system is added to a Cloud Connector machine for instance, the Deploy architecture will allows to actually deploy that runtime.
16 16  
17 -== 3. Key differences in views Deploy & Design ==
18 18  
19 -The System is the key notion for a eMagiz runtime to get created. The eMagiz runtime is a Java based application container in which flows can be made active or operational. In most cases, all Systems in Design are to be located on a machine to effectuate these runtimes on the machines.
18 +== 3. eMagiz Cloud sizing ==
20 20  
21 -However, in some cases the Deploy architecture looks different compared to the Design architecture. In a sense that some system don't get "created" in Deploy. These are the reasons for Systems not to appear in Deploy architecture:
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.
22 22  
23 -* System is only used for API Gateway Access
24 -The system acts as a role and user, and no other integrations are used to and from that system. You can recognize the blue lines with blue rounded boxes containing the number of operations. These systems will be displayed in Design yet not in Deploy architecture. No runtime application is needed as no flows are supposed to run inside these systems. Multi-tenant systems that act as role (with tenants being the users) are also not displayed as system in Deploy Architecture. Below an example of such a case:
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.
25 25  
26 -[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-diffs-design-deploy-1.png]]
25 +[[image:Main.Images.Microlearning.WebHome@advanced*solution*architecture*consequence*size*cloud*1.png]]
27 27  
28 -* System that is used only for Event Streaming integrations
29 -The same applies to systems that are displayed for registering Producers and Consumers for Event Streaming. These systems are not displayed in Deploy Architecture.
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.
30 30  
31 -[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-diffs-design-deploy-2.png]]
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 ===
32 32  
33 -* Systems accessed via Exit Gates only
34 -Applications that accessed via API Gateway operations only are also no displayed in the Deploy Architecture. Exit gates are accessing these applications (displayed as systems) yet the exit gate will run on the gateway container runtime. Therefore, these system don't require any flow to deploy on so no runtimes gets created.
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.
35 35  
36 -[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-diffs-design-deploy-3.png]]
39 +=== 3.4 Impact of Cloud sizing ===
37 37  
38 -There is an exception for that. In case the exit gate is required to run on the on-premises infrastructure of the client for security reasons, the runtime does get created and will be displayed therefore in the Deploy architecture. Apply to environment will not result in the physical deployment of the runtime, but's displayed so that the Deployment plan can indicate progress on deployment. The option Split Gateway needs to be checked in the Design phase
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
39 39  
40 -[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-diffs-design-deploy-4.png]]
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
41 41  
42 -* Hybrid systems
43 -In case a system will contain not only a user management like integration but also another integration (i.e. Messaging) the runtime will be displayed in Deploy architecture as usual. A flow or series of flows need to be deployed on the runtime
47 +This count is also handy when verifying the actual assigned values in Deploy Architecture.
44 44  
45 -* Best practice for Design Architecture
46 -In Design Architecture it is adviced to create one or more on-premises machine that is toggled excluded. Each of these machine will act as a location where runtime not used in Deploy are put. So alignment between Design and Deploy is improved.
49 +=== 3.5 Managing sizing of Event topics ===
47 47  
48 -[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-diffs-design-deploy-4.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:
49 49  
50 -== 4. Key takeaways ==
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.
51 51  
52 -Design and Deploy architecture can differ in view * specific reasons exit which are described in this microlearning.
56 +[[image:Main.Images.Microlearning.WebHome@advanced*solution*architecture*consequence*size*cloud*2.png]]
53 53  
54 -== 5. Suggested Additional Readings ==
55 55  
56 -*
57 -** [[Fundamentals (Menu)>>doc:Main.eMagiz Academy.Fundamentals.WebHome||target="blank"]]
58 -*** [[eMagiz Architecture (Menu)>>doc:Main.eMagiz Academy.Fundamentals.fundamental-emagiz-architecture.WebHome||target="blank"]]
59 -* [[Crash Course (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.WebHome||target="blank"]]
60 -** [[Crash Course API Gateway (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.WebHome||target="blank"]]
61 -*** [[Setting up Exit gate (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.crashcourse-api-gateway-setting-up-exit-gate||target="blank"]]
62 -*** [[API User Management (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.crashcourse-api-gateway-user-management||target="blank"]]
63 -** [[Crash Course Platform (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.WebHome||target="blank"]]
64 -*** [[Understanding Design Architecture - Basic (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-design-understanding-design-architecture-basic||target="blank"]]
65 -* [[Intermediate (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.WebHome||target="blank"]]
66 -** [[Solution Architecture (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Solution Architecture.WebHome||target="blank"]]
67 -* [[Advanced (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Advanced Level.WebHome||target="blank"]]
68 -** [[Solution Architecture (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Advanced Level.Solution Architecture.WebHome||target="blank"]]
69 -* [[Expert (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Expert Level.WebHome||target="blank"]]
70 -** [[Solution Architecture (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Expert Level.Solution Architecture.WebHome||target="blank"]]
71 -* [[Architecture (Search Result)>>url:https://docs.emagiz.com/bin/view/Main/Search?sort=score&sortOrder=desc&highlight=true&facet=true&r=1&f_space_facet=0%2FMain.&f_type=DOCUMENT&f_locale=en&f_locale=&f_locale=en&text=architecture||target="blank"]]
72 -)))
73 73  
74 -(((
75 -{{toc/}}
76 -)))
77 -{{/container}}
78 -{{/container}}
60 +
61 +== 4. Assignment ==
62 +
63 +Please experiment with the options in eMagiz Design architecture to understand the above points.
64 +
65 +
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.
68 +
69 +
70 +
71 +== 6. Suggested Additional Readings ==
72 +
73 +There are no suggested additional readings on this topic
74 +
75 +== 7. Silent demonstration video ==
76 +
77 +There is no demonstration video of this functionality.
78 +
79 +)))((({{toc/}}))){{/container}}{{/container}}