Skip to Content
Last modified by Erik Bakker on 2024/09/02 16:06
From version 10.2
edited by Erik Bakker
on 2022/06/13 08:24
Change comment: Update document after refactoring.
To version 11.1
edited by Erik Bakker
on 2022/06/13 08:25
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -advanced-solution-architecture-diffs-design-deploy
1 +Key differences Design & Deploy Architecture
Content
... ... @@ -1,87 +1,66 @@
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 micro-learning will focus on some differences between the Design and Deploy architecture
3 3  
4 4  Should you have any questions, please contact academy@emagiz.com.
5 5  
6 -* Last update: October 20th, 2021
7 -* Required reading time: 10 minutes
6 +* Last update: April 7th, 2022
7 +* Required reading time: 5 minutes
8 8  
9 9  == 1. Prerequisites ==
10 10  * Intermediate knowledge of the eMagiz platform
11 -* Good working experience in the Design phase Architecture and Deploy Architecture
12 -* Created several API gateway integrations
11 +* Good working experience in the Design & Deploy architecture aspects
13 13  
14 14  == 2. Key concepts ==
14 +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.
15 15  
16 -* Single lane -> Single runtime per types
17 -* Double lane -> Two or more runtime per type to handle failover setups
18 18  
19 19  
18 +== 3. Key differences in views Deploy & Design ==
20 20  
20 +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.
21 21  
22 -== 3. Architecture considerations ==
22 +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:
23 23  
24 -=== 3.1 Architecture components API Gateway ===
24 +* System is only used for API Gateway Access
25 +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:
25 25  
26 -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.
27 +[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-diffs-design-deploy-1.png]]
27 27  
28 -[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-apigw-architecture-1.png]]
29 +* System that is used only for Event Streaming integrations
30 +The same applies to systems that are displayed for registering Producers and Consumers for Event Streaming. These systems are not displayed in Deploy Architecture.
29 29  
30 -Key notes
31 -1. Gateway runtime
32 -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
33 -2. Location runtime
34 -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.
35 -3. Gateway only runtime
36 -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 +[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-diffs-design-deploy-2.png]]
37 37  
38 -=== 3.2 Single lane Cloud setup ===
34 +* Systems accessed via Exit Gates only
35 +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.
39 39  
40 -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 +[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-diffs-design-deploy-3.png]]
41 41  
42 -* Core 01 -> holds the JMS Server and the messaging process container
43 -* Connnector 01 -> holds the API Gateway container and the messaging runtimes
39 +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
44 44  
45 -[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-apigw-architecture-2.png]]
41 +[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-diffs-design-deploy-4.png]]
46 46  
47 -=== 3.3 Double lane Cloud setup ===
43 +* Hybrid systems
44 +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
48 48  
49 -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.
46 +* Best practice for Design Architecture
47 +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.
50 50  
51 -* Core 01 -> holds the JMS Server and the 1st messaging process container
52 -* Core 02 -> holds the backup JMS Server and the 2nd messaging process container
53 -* Connnector 01 -> holds the 1st API Gateway container
54 -* Connnector 02 -> holds the 2nd API Gateway container
49 +[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-diffs-design-deploy-4.png]]
55 55  
56 -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.
57 57  
58 -[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-apigw-architecture-3.png]]
59 59  
60 -=== 3.4 Hybrid Cloud setup ===
61 61  
62 -In the [microlearning](advanced-api-management-running-part-of-your-api-gateway-solution-on-premise.md) 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:
63 -
64 -[[image:Main.Images.Microlearning.WebHome@advanced-solution-architecture-apigw-architecture-4.png]]
65 -
66 -=== 3.5 Memory ===
67 -
68 -For now the memory requirements for API Gateway are the same as for Messaging flows. Please refer to the [microlearning](expert-solution-architecture-determining-needed-memory.md).
69 -
70 -
71 -
72 -
73 73  == 4. Assignment ==
74 74  
75 -There is no specific assignment for now. The correct use of the Design architecture is explained in this [microlearning](crashcourse-platform-design-understanding-design-architecture-basic.md).
56 +Please experiment with the options in eMagiz Design & Deploy Architecture to understand the above points.
76 76  
58 +
77 77  == 5. Key takeaways ==
60 +Design and Deploy architecture can differ in view * specific reasons exit which are described in this microlearning.
78 78  
79 -1. API Gateways can be part of a mixed landscape of Messaging, Event Streaming and API Gateways
80 -2. A single lane setup is usually sufficient for most cases
81 -3. Hybrid setups are possbible but please be sure the ask the right questions before implementing such
82 82  
83 83  
84 -
85 85  == 6. Suggested Additional Readings ==
86 86  
87 87  There are no suggested additional readings on this topic