Patches previously took a minimum of five minutes. Using Amazon ECS … it takes less than a minute—often just a few seconds.
Mike Slavin Principal Architect, TIBCO
  • About TIBCO

    TIBCO fuels digital business by enabling better decisions and faster, smarter actions through the TIBCO Connected Intelligence Cloud. TIBCO interconnects everything and augments the intelligence of the businesses it serves.

  • Benefits of AWS

    • Reduced Amazon EC2 instances by 40%
    • Reduced number of clusters under management from seven to two
    • Reduced patch deployment time from five minutes to less than one minute
    • Reduced scale-out time by 97% 
    • Eliminated manual cluster and port management
  • Services Used

Software-as-a-service (SaaS) applications have empowered people with a range of self-service options, from customer relationship management to business intelligence to email marketing. However, getting data flowing among different SaaS platforms can be challenging, causing users to default to slow, error-prone manual processes. Even if application connectors are available, they are typically designed for IT professionals, not business users.

Software developer TIBCO provides the Simplr service, which makes connecting SaaS applications easy for nontechnical users. With a library of approximately 60 preconfigured connectors and a simple user interface, Simplr enables anyone to link SaaS apps through easy drag-and-drop data flows. Behind the scenes, TIBCO’s connectors run as a suite of microservices to do the hard work of moving data between services.

Simplr was originally built on Amazon Web Services (AWS) using a microservices architecture hosted on virtual machines (VMs) on a cluster of Amazon Elastic Compute Cloud (Amazon EC2) instances. As the Simplr service grew, TIBCO wanted to reduce the complexity of managing its architecture, streamline the development process, and reduce costs by using fewer Amazon EC2 instances.

To accomplish these goals, the company migrated Simplr to a new architecture built on Docker containers and managed by Amazon Elastic Container Service (Amazon ECS). TIBCO recognized that a containerized architecture would provide tool-chain consistency for its developers and make it easier to manage, scale, and improve its services.

Before adopting Amazon ECS, Simplr was deployed on Amazon EC2 clusters in Auto Scaling groups, each fronted with the Elastic Load Balancing Classic Load Balancer. In addition, the company ran customers’ applications created through Simplr on “engines,” consisting of a pool of Amazon EC2 instances managed by the Simplr Engine Service. The company uses Amazon Simple Queue Service (Amazon SQS) to handle queue jobs to the engines.

This architecture performed well but was complex to manage and update, and the Simplr operations team had to manage many Auto Scaling groups. “It was cumbersome and painful having to manage all those connector groups, so we wanted to eliminate them entirely and use a different approach,” says Mike Slavin, principal architect at TIBCO. “We adopted Amazon ECS and Docker to make our application ecosystem easier to manage and update while reducing our Amazon EC2 footprint. This approach integrated with the other AWS services we were already using, which simplified and sped up our migration process.”

TIBCO ECS Architecture

TIBCO migrated its virtual machine-based microservices to Docker containers running on Amazon ECS and also migrated to the Application Load Balancer, so the company can dynamically route traffic to the containers managed by Amazon ECS using path-based routing rules. To ensure the engines running customer applications had stopped processing customer workloads before shutting down, TIBCO uses Auto Scaling lifecycle hooks registered with AWS Lambda serverless compute functions. When TIBCO needs to scale down the number of containers running due to a drop in demand, Auto Scaling lifecycle hooks put the containers that need to be terminated into a draining state, stop incoming connection requests, and allow the containers to finish processing any running workloads before being shut down. To manage its large number of container images, the company uses Amazon Elastic Container Registry (Amazon ECR) to simplify image updates, storage, and deployment.

Although the system primarily uses in-memory storage, TIBCO relies on Amazon Simple Storage Service (Amazon S3) for storing DevOps artifacts, runtime files, and data in transit from one SaaS service to another. It also uses Amazon Simple Email Service (Amazon SES) to broadcast emails to customers.

The company took a carefully planned, phased approach starting with one Auto Scaling group. It analyzed its entire continuous integration/continuous deployment (CI/CD) pipeline, identifying the changes required at each step to create Docker containers, Amazon ECS services, and task definitions. Because of the consistent deployment methodology enabled by Docker containers, once TIBCO had ironed out the pattern for this migration, it could apply it to all the other services.

The migration process took approximately four months and has achieved all its intended benefits. “We now use Amazon ECS to manage when containers are started up on the Amazon EC2 cluster,” says Slavin. “Each connector is modeled as an independent Amazon ECS service. We have one Amazon EC2 cluster for our connectors, and one Application Load Balancer that connects incoming requests to the correct service.” The shift enabled TIBCO to reduce the number of Amazon EC2 instances it uses for TIBCO Simplr by 40 percent—and it now only has to manage two TIBCO Simplr compute clusters, instead of the previous seven.

Using Amazon ECS has greatly simplified TIBCO’s DevOps and CloudOps workflows. “All that complexity has gone away,” Slavin continues. “When we need to make an update, we create a new Docker image on the DevOps jump server, update Amazon ECR, and send an update command. The pattern is the same no matter what cluster, microservice, or connector we’re updating.”

Those updates are much faster, too. “We used to have to deploy all the Web Application Resource files and restart the entire Auto Scaling group to update a single Simplr connector. Patches previously took a minimum of five minutes,” says Slavin. “Using Amazon ECS, we update the task definition to point to a new Docker image, and it takes less than a minute—often just a few seconds.”

In addition, the system has become much more responsive. “We used to scale CPU and memory at the Auto Scaling group level, requiring us to spin up a new Amazon EC2 instance in that cluster if the system was getting hammered,” says Slavin. “That could take 5–6 minutes. Amazon ECS can start up a new task in 10–15 seconds.” The company can more easily keep its solutions up to date, keeping pace with the rapidly evolving SaaS solutions that its customers rely on Simplr to connect.

Learn how to run containerized applications in production using Amazon Elastic Container Service.