Re: [IBMiOSS] [EXTERNAL] Re: Ports and routes needed to replace very large numbers of green screens

Hi Kelly,

one of the reasons you can’t find that much useful info online is that companies normally charge around 300 dollars an hour for infrastructure consulting on apps of this type of scale. we do this type of work at various banks and insurance companies who have both mainframe and IBMi legacy apps mixed in with a multitude of other applications stacks, including cloud and mobile.

heres a few tips on lessons learned along the way and what you should consider before you start, so as you say you don’t paint yourself into corner.

don’t tie enterprise routing to something such as Express based routing. from day one implement a proxy/gateway for the central point of access to your apps. behind this single IP/Port number you will be implementing a mesh or hierarchical grid of services/apps. usually a hybrid. some companies such as IBM use base + organisation + space + environment + app(+subapp) to implement and configure routes. other such as APIGEE, Kong etc have their own structures to support this hierarchy. by keeping the is separate from the beginning and keeping it simple initially you will be able to evolve as you learn without development disruption or any real downtime. the main benefit of this is that its all url based (and so assumes internal DNS) so if your internal app design and subsequent mix of endpoints/ports/webservers changes you don’t disrupt. its also optimised for traffic routing so you won’t grind to a halt even in massively complicated meshes with thousands of apps. from our experience using all major variants, Nginx combined with Kong is the most cost effective starting point for these proxy/gateways that scale to as big as you can get. you can also implement load balancing at this level too.
app level routing is necessary but look at implementing your own app routing framework (based on someone else's is fine) in your apps where possible for reasons i mentioned in my earlier message.
do an initial rough cut of what your current app structure from a business function perspective, and map current application artefacts to this. X-Analysis can be a way of shortening this analysis by a few months. based upon the current mapping to an estimated outline of potential new apps (node.js, mobile, .Net whatever) create an initial hierarchal mesh design in your proxy/gateway that allows for evolution and growth. this snapshot and initial design is purely to help scope the scale of the diversity of apps in objective terms rather than subjective guesswork. who many apps/webservers/ports In some projects we eliminated as much as 70% redundancy by doing this with forensic analysis rather than using good old tribal knowledge.
make sure you keep your data services separate so they can be scaled and routed within the application and across the enterprise. it also allows for external exposure of services when integrating with outsourced dev, cloud, Mobile partners, customer apps, IOT etc
the ultimate decision on whether to implement an app or a sub app(and so web server instance/portno) will come out of the three main areas i mentioned in my earlier comment: ownership, scalability, security. and all three of these can change as things evolve. some of the questions you are asking will almost answer themselves once you have an objective potential scope.
by doing some upfront analysis across the application you can look at developing some utility functions/apps which can help avoid redundancy but also help designing a good mesh of potential apps/services before you even start. You may need to implement OAUTH/JWT or other security mediation mechanisms at an app level in certain instances as you grow. but ALWAYS temper this with the functional business drivers and owners. sometimes a bit of redundancy is a necessary trade off for expediency.


love to hear how you get on


Stuart Milligan
Cell SA: +27 61 651 7074
Dir SA: +27 (0)21 012 5078
Dir NA: +1 917 267 7523
UK: +44 (0)238 097 1176
stuartm@xxxxxxxxxx