In a previous article I wrote about the first 5 of 10 common application infrastructure issues I come across as a solution architect, this is part 2, the second 5.
Synchronous dependencies on remote applications
As new applications have been deployed into an infrastructure so the intra-application connections between them have been implemented. It’s not un-common for a CRM system to link into an ERP system which links to a sales order processing system. If these apps were implemented one at a time then unless there’s a messaging system in places it’s likely the application connections will be direct synchronous coding. If these applications are on the same LAN then it’s reasonable to protect against most causes of downtime, however as soon as an application becomes remote the performance of your wide area network (or the Internet with public cloud services) now becomes a big dependency for your application infrastructure. Router changes, firewall reboots, WAN link maintenance could now all stop your CRM system updating a record in your ERP system. Plan for this, aim for asynchronous messaging, aim for queuing, aim for retries, do anything which handles a “network timeout error” gracefully!
No central authentication services
Throughout your application infrastructure there will be applications which run as services, require Windows authentication or just need a user context to run under. There is no reason why you cannot have a centralised authentication services tier to secure the complete environment, even if you decide to separate it from your internal directories services. Two AD domain controllers can happily run on two tiny virtual machines, in their own firewall zone, yet still provide a centralised security policy and user account base.
Hard-coded IP addresses
When applications get implemented there can seem to be many good reasons why hard coding an IP address into application code, server configs or user configs; there may be poor name resolution services, the application might have been designed to work that way or no one really thought about it. However, come a time when you need to re-locate an application and you may be in for a hard time. If the new server is in a different physical location then your subnet may have gone never mind the same IP address. In the era of application infrastructures combining private cloud, public cloud and on-premise services, and the transformation of applications from one to the other, now is the time to force your application teams to stop using IP addresses.
Security policies created from an allow all not a deny all
When you deploy an application into a security sensitive environment, e.g. Internet facing, you will need firewalls to police the network traffic within your application infrastructure. This can be quite a culture change if previously you’ve always deployed the application in an un-secure LAN environment where there were no traffic controls. When you have to re-deploy into a secure environment learn what firewall rules your application needs, not what it doesn’t need. Start with a firewall policy that allows nothing through, then slowly add rules until the application works as expected.
No load testing
When you implement a new application you need to know how fast it can work, how many orders a minute can it handle when every CPU is running at 100% for example? Have the knowledge of what the most the system can handle in ideal conditions is. Otherwise, when at month end when your users complain the system is slow do you know if it really is or do they just feel it is? Have numbers to hand which can compare current performance to a known maximum performance. This can also help your capacity planning by aligning a business metric (e.g. orders per minute) to infrastructure performance data.