Amazon Web Services (AWS) entered the integration space by providing File Transfer and API Gateway capabilities into their platform offerings. AWS continues to build services based on customer input; it was inevitable that they would enter into the broader integration space. In reality, we do not consider AWS a strong alternative to Axway, and I will explain my reasons in this article.
AWS is a strategic technology alliance for Axway. Axway uses AWS for its entire managed cloud service. In addition, Axway is an AWS Advanced Technology Partner and one of seven partners globally (out of a 70,000-partner ecosystem) with dual competency in healthcare and life sciences. Like many larger companies in the enterprise software market, AWS is friend and (potential) foe when it comes to technology partnerships.
“In total, we drive approximately 62 million transactions per year on the Axway AMPLIFY platform, hosted on AWS, and we continue to be very satisfied with the performance, reliability, and availability of the Axway EDI and API solutions,” says Rick Rubin, CEO, and President of OneHealthPort
One of Axway’s clients recently contacted me with an interesting perspective. He said that they are having a challenge with certain file transmissions because the partners that are exchanging the files are in a different geographic region. With the Axway Gateway running in AWS North America and the partner located out in Australia, the latency was too great, and they were missing critical SLAs.
My client discovered that AWS has an SFTP Server offering. They decided to do a POC where they spun up an AWS File Transfer service in the Australia AWS region. The partner uploaded the files to AWS Australia which fed an S3 bucket on the back end. They then used S3 replication technology so that the file was replicated to an S3 bucket in AWS North America for delivery to the consuming application. The following illustrates the use case.
- Partner Uploads the file by connecting to Amazon’s SFTP service in the Australia region.
- AWS replicates the file to the AWS US East Region.
- Axway Gateway uses the S3 pluggable transport to fetch the file from the S3 bucket. It can look for files on scheduled intervals.
- Axway gateway delivers the file to the mainframe via Axway’s robust PeSIT protocol.
My client was quite proud of his successful POC and said that he was able to set up AWS’s SFTP Server in minutes and the whole POC was straightforward to implement. It raised some questions in his mind about Axway’s value. It seemed in his mind that AWS SFTP Gateway was simple to set up and on face value was a cheaper and faster alternative to using Axway’s B2B Gateway.
The primary challenge with AWS File Transfer is that it only supports the delivery mechanism to exchange files with S3 Buckets. It misses the following key capabilities which make the implementation of enterprise shared service gateways unrealistic:
No rules engine to automate file processing and orchestration
Once the file is ingested, decisions need to be made on what to do with the file. For example, simple file driven orchestrations such as anti-virus scanning, PGP encryption/decryption, Checksum validations to verify the entire file was ingested, duplicate checks, character conversions, for example, to make compatible with non-distributed environments (e.g. ASCII to EBCDIC), uncompressing archives and evaluating files in the archive. Ultimately, decisions need to be made on where to route the files to their ultimate destinations.
In AWS you need to write Lambda code to implement these types of orchestrations. The more code you write, the more complex and unmanageable the environment becomes.
Axway provides a native rules engine that enables you to do all the complex stuff without writing code which makes the whole offering more maintainable and reduces the costs of expensive IT resources to set up file exchange.
No enterprise-wide command and control
When we start looking at large enterprise implementations with geo-disbursement, command and control becomes critical with self-service so that the data exchange stakeholders can subscribe and manage their ecosystems. Imagine you have dozens if not hundreds of AWS file transfer gateways deployed in multiple global regions?
You have no way of centrally administering all of those environments. No ability to get centralized visibility presenting the file transfer activity in a non-technical fashion. No ability to create rules to proactively notify you if certain files did not get processed?
Axway provides a centralized command-and-control governance layer which enables our customers to create flow patterns that can be exposed to the lines of business so they can manage their file transfer setups in a self-service fashion without writing a single line of code. Axway provides centralized visibility that enables customers to get proactive insights before there is a business impact.
Lack of protocol support
AWS SFTP Gateway only supports a limited set of protocols – SFTP, FTP/s, and FTP. In reality, to create a successful enterprise-wide shared service, you need to support a much broader ecosystem of communications protocols such as AS2/3/4, SWIFT, Connect:Direct (NDM), RosettaNet, JMS, Azure Storage, Google Storage, HTTP/s, and the list goes on. As more users adopt the service more protocol support will be needed.
Axway supports all industry protocols. Our customers have complete flexibility about how they exchange files with their partner ecosystems. This makes them easy to do business and they can set up new clients faster.
When dealing with enterprise shared service, you need a gateway that can scale for the masses.
Axway has a unique and market-leading approach to scaling the gateway without consuming significant resources. The gateway has native application clustering where there is no limit to the number of nodes that can be deployed in the cluster. Axway has implemented some of the biggest file exchange gateways in the world.
While the AWS File transfer service may seem easy to use and low cost on the service, peel the onion just a little and you find that it’s is not practical for enterprise-class file exchange. The following describes the ultimate recommendation that I made to my client.
- Australia Partner uploads the file by connecting to the Axway gateway in the Australia region managed by Axway (localize the client experience and eliminate latency)
- Axway Gateway automatically routes the file to the Chicago Mainframe via PeSIT protocol
Axway can provision our solution in the AWS region quickly. In fact, Axway uses AWS as the hosting provider when we manage the gateway for our clients. By deploying the Axway gateway solution in Australia, my client can gain the following key benefits over using the AWS File Transfer Service:
- Offer the trading partner a broader range of protocols to make it easier to do business.
- Eliminate the need to write code to automate the processing and routing of the files which eliminates the complexity and overall cost of ownership.
- Leverage Axway’s very own PeSIT protocol that enables the client to deliver the file to their on-premises Mainframe in North America at VERY high speed, guaranteed delivery, and guaranteed payload integrity. This reduces risks because the file will get there with speed and it avoids having to route files to another AWS region that is in a closer geo proximity to the final destination.
- Centralized command and control mean that my client has a single cockpit view into everything regardless of the geographic topology. This again will save significant costs in managing individual environments.
- Self Service so that each business group can manage their file exchange ecosystems without having to learn the underlying technology. This will create greater adoption at a lower cost.
Learn the value of a modern MFT solution.