Last modified by Eva Torken on 2023/08/10 11:12
Show last authors
1 {{container}}
2 {{container layoutStyle="columns"}}
3 (((
4 In a previous microlearning on this [[subject>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-design-understanding-design-architecture-basic||target="blank"]] we have learned the basics of the Design Architecture overview. In this microlearning, we will expand our knowledge of Design Architecture. This is to get an even better understanding of what the Design Architecture overview is about and how you can best utilize this within the context of your project(s). Having this knowledge will make it easier to make a correct architectural decision in the long haul.
5
6 Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
7
8 == 1. Prerequisites ==
9
10 * Basic knowledge of the eMagiz platform
11
12 == 2. Key concepts ==
13
14 This microlearning centers on understanding design architecture.
15
16 With Design Architecture we mean: The desired overview of where the instances are deployed, on which machines, and how many resources it takes to deploy these instances
17
18 The focal point of this microlearning will be to provide context on the Design Architecture page:
19
20 * Approval (Cloud, Topic Storage, etc.)
21 * Ratio between size and number of runtimes (Golden ratio)
22 * Impact / Consequence of changing something in Design Architecture
23 * Why do Design and Deploy Architecture differ from each other (in some cases)
24
25 == 3. Understanding Design Architecture ==
26
27 In a previous microlearning on this [[subject>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-design-understanding-design-architecture-basic||target="blank"]] we have learned the basics of the Design Architecture overview. In this microlearning, we will expand our knowledge of Design Architecture. This is to get an even better understanding of what the Design Architecture overview is about and how you can best utilize this within the context of your project(s). Having this knowledge will make it easier to make a correct architectural decision in the long haul.
28
29 The focal point of this microlearning will be to provide context on the Design Architecture page:
30
31 * Approval (Cloud, Topic Storage, etc.)
32 * Ratio between size and number of runtimes (Golden ratio)
33 * Impact / Consequence of changing something in Design Architecture
34 * Why do Design and Deploy Architecture differ from each other (in some cases)
35
36 === 3.1 Approval ===
37
38 The first point of attention is the approval process. As deploying your integration data model to the cloud will cost resources there needs to be an approval process to ensure that you as a customer have the right to use a certain amount of cloud resources. The same applies to when you would use the Event Streaming pattern and want to increase (or decrease) the amount of topic storage you are contractually allowed to use.
39
40 To get approval a contractual agreement needs to be struck between you as a customer and eMagiz. This contractual agreement could be struck via a partner construction. To start the approval process it is best to contact the person with whom you have the most contact when it comes to the eMagiz platform (in most cases your partner manager). They will then ensure that the request is communicated to the proper authorities for approval.
41
42 After the contract is signed and the increase (or decrease) of Cloud and/or Topic Storage is configured you will be notified that the approval has succeeded. At this point, you can continue expanding your integration data model.
43
44 === 3.2 Golden Ratio ===
45
46 The runtime is the component into which the individual integration flows are deployed. It's a Java-based application container that can run in the Cloud or Local. A runtime is visually displayed and described in the eMagiz iPaaS Portal as a process container (holding the onramps, offramps, routing, error), an event streaming container (holding the event processors), a gateway container (holding all entry and the exit gates), or a connector (holding the exits and entries).
47
48 One critical element in Design Architecture is determining how many runtimes can run on a specific machine. For a detailed explanation on that, I would like to refer you to the following [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Expert Level.Solution Architecture.expert-solution-architecture-determining-needed-memory||target="blank"]]. As a general rule of thumb, we use a placeholder of 1GB of memory per runtime. That means that roughly speaking you can safely place 8 runtimes on an L machine. You will notice that when you dig into the numbers deeper the number can shift based on the actual implementation.
49
50 === 3.3 Impact of changes ===
51
52 In theory, changing anything in Design Architecture has no direct impact. In practice, however, it is good to be aware of the potential consequence. Imagine the following scenario, you and a few other colleagues are working within the same integration data model. You are currently moving around runtimes with the intent of actualizing that change one week later. However, in the meantime, a colleague of yours needs to expand the integration data model that is running on the cloud with a new runtime. As you all are working in the same integration data model eMagiz will actualize **all** changes when your colleague presses Apply to Environment in Deploy Architecture. So be aware of when you change things and when you do ensure to communicate with all stakeholders related to the project how you plan to actualize those changes.
53
54 === 3.4 Design vs Deploy Architecture ===
55
56 In the previous segment, we talked about the impact of changing things in Design Architecture. In this segment, we will look at some scenarios in which the Design Architecture view can differ from the Deploy Architecture view. There are three main reasons why both of them differ:
57
58 * This is the first time you open Deploy Architecture
59 * This means you need to spin up your cloud infrastructure for the first time
60 * There is no flow related to the runtime embedded in the release
61 * Runtimes won't show up in Deploy Architecture when no flow should be deployed on them within the currently active release
62 * The runtime is excluded in Design Architecture
63 * With this functionality, you explicitly mention that a certain runtime should not be deployed
64
65 Knowing this should make you better equipped to handle 'unexpected' situations you occur while implementing your data model with the help of the eMagiz platform.
66
67 {{info}}Note that the reason why you see a specific runtime can differ per environment.{{/info}}
68
69 == 4. Key takeaways ==
70
71 * Key considerations when dealing with Design Architecture are:
72 * Approval (Cloud, Topic Storage, etc.)
73 * Ratio between size and number of runtimes (Golden ratio)
74 * Impact / Consequence of changing something in Design Architecture
75 * Why do Design and Deploy Architecture differ from each other (in some cases)
76
77 == 5. Suggested Additional Readings ==
78
79 If you are interested in this topic and want more information on it please read the help texts provided by eMagiz
80 )))
81
82 ((({{toc/}}))){{/container}}
83 {{/container}}