[GitHub] [trafficcontrol] srijeet0406 commented on a diff in pull request #6872: Traffic Ops Service Oriented Architecture blueprint

[GitBox <gi...@apache.org>]

srijeet0406 commented on code in PR #6872:
URL: https://github.com/apache/trafficcontrol/pull/6872#discussion_r886972611


##########
blueprints/to_soa.md:
##########
@@ -0,0 +1,159 @@
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+# Service Oriented Architecture for Traffic Ops
+
+## Problem Description
+Traffic Ops (TO), in its current form, can be best described as a monolithic application.
+All the code and logic for TO resides in one single application. Hence, making even a minor 
+change to one area of TO requires a redeploy of the entire TO application. This is not ideal, 
+as it adds the additional burden of deploying a huge application, for a small change. In order to 
+move faster and in a more seamless manner, TO needs to be refactored so that we can redeploy/ restart 
+one part of the application without affecting the other parts.
+
+Rewriting the entire TO application will be a highly time and resource intensive effort. However, we could 
+refactor TO, to convert it into a Service Oriented architecture (SOA) style product. This would allow us to
+decouple new features and functionality from the monolith while also providing the opportunity to re-factor out 
+existing features in the future.
+
+## Proposed Change
+The goal is to transition TO from a monolithic application to a more service-oriented architecture.
+What this means is that TO will be more of a "collection of services". New features and functionality will be
+added as stand-alone services with stand-alone testing, deployment and scalability. TO, the way it is today, will serve
+as `TO-core`, and any new service will be added as a "backend service", fulfilling the requirements of that service, and nothing else.
+The user would still send a request to the TO API. TO, upon receiving this request, would check in its configured "backend routes". If 
+a match is encountered, TO would act as a reverse proxy for this service. This means that TO would simply forward the request to the backend
+service, get the response from the backend service and send it back to the user. From the user's perspective, this should be totally transparent
+and seamless. Once TO starts supporting the SOA pattern, we would be able to scale the individual services independently of TO core.
+![](img/to-soa.png "Architecture of TO as SOA")
+
+### Traffic Portal Impact
+Any new Traffic Portal (TP) changes that the backend service requires, will be required to be added as modules to the current TP architecture.
+As for the TO refactor, no TP changes are required.
+
+### Traffic Ops Impact
+TO will need to read a new configuration file(supplied with the `backendcfg` option) on startup. This file will list the routes that will be served by the backend services, some route 

Review Comment:
   It doesn't need to be, but I didn't want to overload the current TO config any more. It's already pretty big and has lots of stuff in it as it is. 



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@trafficcontrol.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org