Blog
Modernisation
AWS

Why some customers are hauling out traditional middleware and moving it all to AWS

March 14, 2022

Integration has come a long way in the last 20 years.

From traditional Service Oriented Architecture patterns to cloud integration, microservices and citizen iPaaS integrators, businesses around Australia and New Zealand have gone through a rapid series of changes and challenges with their integration stack.

What we’re seeing now is the evolution away from the traditional ‘middleware’ layer where enterprise wide integration is connected through a central integration hub or ESB function, to building API and cloud enabled serverless integration models on whatever cloud provider is of choice.

And what we’re seeing with a vast part of the market,  is that AWS is that choice.

Integrate on AWS vs Buy Traditional Middleware

The old build vs buy dilemma for integration is nothing new. Bitter and expensive experiences with one or the other leave decision-makers and decision influencers with strong biases.

A good rule of thumb on when to build vs. buy is to align the integration model to the digital transformation strategy. Does the strategy focus on the core tenant of flexibility? Or is security of utmost importance? What are the values and ‘North Star’ of the business and technical ethos?

Building custom integrations across AWS brings many benefits, mainly the flexibility of doing integrations that directly addresses the solution needed. However, anything custom-built runs the risk of architectural or security code or configuration issues. There also may be talent lock-in issues where your system is reliant on one or two engineers and their undocumented in-house IP. There also might be key features such as authorisation, reporting or analytics that go by the wayside - let alone the cost of trying to do it yourself.

All of these challenges are likely. So why should an organisation consider integrating on AWS and disregarding or decommissioning their traditional middleware?

Enter Seisma's Integration on AWS serverless service (otherwise known as Integration Modernisation)

Okay, so the name and definition of ‘serverless’ can be misleading, as there are servers, after all. Serverless refers to a cloud computing model (i.e. AWS, currently leading the way in serverless technology) in which the platform manages the allocation of infrastructure, latency, scalability and availability. There is no infrastructure to manage, no patching, no perimeter management and pay-as-you go modelling. It allows users to focus on building and maturing their applications and digital services, without having the arduous task of managing infrastructure.

For quick reference, serverless can be grouped into BaaS (Back-End-as-a-Service) and FaaS (Functions-as-a-Service). Integration capabilities on AWS fit into the FaaS group - including AWS Lambda and AWS API Gateway.

In general, an integration platform needs capabilities such as messaging, routing, transformation, event bus, orchestration of workflows and API management - all architected and developed in either on-prem or cloud environments. To do this yourself requires a large team of integration experts and engineers (who have some free time on their hands), plus a whole lot of AWS savvy. Not usually something you see every day.

Luckily, the team at Seisma have been working with some of our great customers - Nova Energy and Mercury Energy across a number of AWS tooling, to develop integration capabilities. Some of these tools include:

  • AWS SNS
  • AWS SQS
  • AWS Lambda
  • AWS Step Functions
  • AWS API Gateway
  • AWS AppFlow
  • AWS EventBridge
  • AWS Glue for Serverless

So why? What are the benefits and compelling reasons to do this?

Up to 60% of technology projects and transformations stall at the integration stage. Not a lot of people know that - the impact to innovation and change is huge when the integration layer (usually traditional ESB’s such as MuleSoft or IBM Gateway) is built inadequately without agility.

Imagine an interconnected world - across cloud and hybrid where:

  • All the features in an integration platform are available as building blocks type services in the public cloud, allowing modular development and agility as the company grows;
  • If there are no operations (NoOps) needed for this platform to perform - as in provisioning and management including scaling, resiliency, and availability, are provided out-of-the-box, on demand, 24-7-365.
  • The pricing is based on usage of the platform rather than a 3 or 5 year perpetual licensing program that quickly becomes redundant.
  • Everything is connected, yet customers are delivering $700k AUD over three years on middleware costs.

In a real life example, Seisma has worked with New Zealand’s Mercury Energy to deliver them integration savings, by moving them across to AWS integration modelling. Through strategy, consulting, design and implementation we were able to decommission their heavyweight and inflexible MuleSoft ESB solution and transform it into a lightweight, cost-efficient and scalable integrated AWS solution.

Want to know more? Contact us to discuss Integration on AWS.

*This blog is sourced from acquired company Fronde.

Case Study

Bendigo Bank's Transformation Journey with the Bendigo Lending Platform

Case Study

Seisma Group facilitates seamless Google Workspace integration: Loom's Migration to Atlassian

Blog

Harnessing Generative AI with Salesforce: Transforming Banking Operations

Case Study

JJ’s Waste & Recycling Leverages Microsoft Fabric for Scalable, Cost-Effective Data Management