Unless you haven’t been paying attention, you probably recognize that Kubernetes (or K8s) is the de facto way to automate the deployment, scaling, and management of containerized applications. I believe Kubernetes owes its success to a number of factors. First, it’s open source so it’s very easy to consume. Second, it’s supported by a very broad number of enterprise software vendors whether you deploy k8s on-premises or in the cloud. Third, its governance model involves vendors, developers, and end-users at the CNCF rather than having a single corporate sponsor.
As technology evolves, so too must our approach to developing software. Organizations must invest in technologies that can be used in both public clouds and their private clouds for different purposes. They must be able to scale up and down depending upon demand. They must be portable so they can avoid lock-in to a specific cloud or vendor. Using a common open source platform across their infrastructure increases efficiency by providing one standard tool across hybrid infrastructure.
Integrating data from different sources, such as an application running on-premises and in the cloud, is often necessary and challenging. Therefore, just like your infrastructure, integration Platform-as-a-Service (iPaaS) solutions should be cloud-native and open source when possible.
Integration architecture solves two common integration problems. One problem is enterprise application integration that creates automation between applications. The second type of integration problem is the synchronization of disparate data sources between systems. Both patterns require a robust iPaaS that meets all the integration requirements for their unique environment.
Legacy iPaaS vendors such as Dell Boomi, Mulesoft, and Tibco, emerged before the advent of cloud services. Like other on-premises applications from that era, these old school iPaaS systems resemble the other monolithic applications that enterprises are trying to modernize. They pre-date the era of composable infrastructure where DevOps teams create infrastructure stacks from the best-in-breed infrastructure applications from multiple vendors rather than a single vendor stack.
In contrast, modern iPaaS solutions should embrace cloud best practices. This means modern iPaaS should be architected using microservices developed using CI/CD, containerized and deployed on Kubernetes—in other words, they should be cloud-native. Moreover, the integrations built using a cloud-native integration platform should themselves be cloud-native. This means they can be expressed as YAML and deployed and managed as code in a GitOps fashion.
But a cloud native integration platform is much more than new for new’s sake.
A cloud native integration platform automates and accelerates the linking of applications and data, and is much faster than writing custom integrations on a one-by-one basis. And unlike legacy iPaaS tools that require extensive training and highly-specialized skills to create and maintain integrations, developers can self-serve with cloud native integration platforms using the same development and deployment practices they use for all their other projects.
iPaaS systems should be easy to use and adapt, and should increase developers’ productivity by increasing the speed at which they can deploy and maintain integrations. An iPaaS should not require expensive consultants, extensive vendor certifications, and complicated license schemes to support. TriggerMesh has created an iPaaS platform that doesn't require extensive training and certification and can significantly reduce integration costs while increasing business agility.
You Created Containerized Applications; Now What?
You have containerized your applications, deploying them on-premises and in the cloud. Maybe you are doing this to modernize the platform you deploy to, or perhaps you want to create new microservices. No matter the reason, modern businesses need to integrate their applications with other applications. So why would you modernize your applications and not modernize your integration platform?
Kubernetes is Cloud-Native, Integration Should be Too
Early Kubernetes users primarily deployed new applications that were developed cloud natively to K8s. increasingly, more and more users are updating their legacy applications by containerizing them and deploying them on Kubernetes. Though modernization through containerization has a benefit, it fundamentally changes how your applications are deployed. Monolithic applications are being replaced by containerized applications and decoupled services. It is also unlikely that all your applications and data sources are cloud-native.
Therefore, you need a tool that bridges hybrid architectures. As is the case with Kubernetes, there are a set of criteria that should apply to your iPaaS: cloud-native, declarative API, event-driven, open source, and DevOps-friendly.
Cloud-Native is an approach to designing applications based upon building software using services provided by clouds such as Amazon Web Services, Google, and Microsoft Azure. It can also refer to developing software in a manner that makes it easy to move from one cloud service provider or private cloud to another. A prime example is deploying an application to Kubernetes, which can run on multiple clouds or your own data center. TriggerMesh can run on any conformant version of Kubernetes on-premises or in the cloud.
Kubernetes' strength has been the introduction of a declarative mindset to application design and management. With the Kubernetes API, you declare the state of your application and let the controllers do whatever it takes to observe the desired state. Using the declarative API, you can create, update and delete objects using manifests written in YAML that are intent-based.
TriggerMesh integration-as-code follows the same pattern. And TriggerMesh Integration Language (TIL), which is an extension of Hashicorp Configuration Language used to create Terraform plans, provides a human-readable syntax for designing multi-cloud application flows and data syncs. Under the hood, TIL creates the YAML integration manifests which can then be deployed and managed as code.
Today’s enterprises must be able to quickly adapt to changing conditions. Data is available from an ever-growing number of sources. In addition, the modern enterprise is becoming event-driven. A cloud-based solution that provides real-time integration with multi-cloud capabilities should be part of every enterprise's digital transformation strategy.
An event is a way of capturing a change in a system. Events occur in a continuous stream as things happen. By taking advantage of this constant stream of events from technologies such as Apache Kafka or Google Pub/Sub, applications can take action in real-time on changes from virtually any system.
To embrace event-driven development, enterprises need to create new apps quickly and easily without having to worry about legacy code. Cloud-native technologies enable organizations to rapidly deliver new business services by leveraging public clouds for infrastructure, platform, software, analytics, and automation but still need to integrate with their legacy counterparts.
Event-driven architecture isn’t a new concept. However, when modernizing from monolithic applications to microservice architecture, containers, and serverless computing environments, an event-driven approach extends the resiliency, agility, and scalability of cloud native architecture by adding reactivity and responsiveness.
Every cloud provides events, as do many other applications that are a source of events. Typically these events are collected via Apache Kafka or Apache Pulsar in real-time or via Enterprise Service Buses (ESBs) in a queued fashion. These events have meta-data about the event along with data in a payload. TriggerMesh embraces the CloudEvents specification for describing event data in common formats to provide interoperability across services, platforms, and systems.
IT leaders must fundamentally provide flexibility and agility for their enterprise. If you can’t compete on agility, you’re going to get left behind by the competition. Open source enables technology agility, typically offering multiple ways to solve problems. In addition, open source helps keep your IT organization from getting blocked because a particular capability isn’t available from a vendor. Instead of waiting for the vendor to deliver that capability, you can create it yourself.
Open Source allows you to start small and quickly with free software, which may be modified by others for their purposes. Then, when your needs grow, you can move up to commercial solutions. You don't need to pay for an enterprise license if you're not planning to use any features beyond basic functionality. You have the option of trying out different options, picking the one that works best for you, and then scaling up with a commercial solution. TriggerMesh provides an open source path with our Apache Software Licensed open source platform and provides commercial support for those organizations that need more help.
DevOps has always included automation as a key tenet. Taking the same methodologies that have been used in software like automated build systems and source control and applying them to infrastructure deployment. Not only should your infrastructure be easy to deploy but so should your applications and even the integrations between these applications. Beyond that, all of these elements should be composable using the best solutions at each level of the stack.
One of the standard tools of the DevOps toolkit is configuration management, which is typically imperative, requesting deployment or configuration on stateful systems. In contrast, Kubernetes operates declaratively, enforcing the desired state of services through control loops. DevOps have embraced this type of “as-code” approach because it efficiently increases the speed of shipping ideas while reducing the risk. The versioned infrastructure allows us to reason over the state and understands the application and service changes in response to updates to the code.
Infrastructure-as-code solutions like Chef, Hashicorp Terraform, and Red Hat Ansible have tried to keep pace with the evolution of systems and services. Still, as the enterprise consumes more and more cloud services, that future lies in integration-as-code so that all elements are represented as source code that can be versioned, tested, templatized, and shared. This makes deploying and managing integrations easier while realizing the benefits of versioned source control.
The De Facto Integration Platform for Kubernetes
Regardless of where an enterprise is in its cloud journey, they need integration. TriggerMesh has always been developed in the cloud and with an eye to the challenges enterprises face with legacy infrastructure. Organizations can’t simply lift and shift everything to the cloud.
TriggerMesh's goal is to become the de facto integration platform for Kubernetes; the design points of TriggerMesh's cloud native platform are very similar to the design points of Kubernetes as it's open source, cloud-native, includes a declarative API, and uses a domain-specific language that is similar to what DevOps already use for deploying cloud infrastructure.
Our catalog of pre-built connectors covers a wide variety of on-premises applications and cloud services. This allows us to connect everything from an enterprise service bus (e.g., IBM MQ) to hundreds of other applications and cloud services.
As an iPaaS vendor, TriggerMesh is not striving to be a leader in cloud integration or application integration but enterprise integration. No matter how complex the integration needs of an organization are, TriggerMesh wants to help them overcome integration challenges for any application. TriggerMesh is committed to reducing integration costs while delivering top-notch customer service. A great way to start with TriggerMesh is to download the Open Source TriggerMesh Cloud Native Platform to get started and contact us if you need additional help.