Microservice architecture discussions are often heavily focused on alternate ways to build applications, but the core ideas behind it are relevant to all software components, including integration. Integration runtimes have changed dramatically in recent years. Lightweight runtimes that can be treated as “cattle not pets” enable automated infrastructure orchestration, elastic scaling, continuous integration and deployment, and generally encourage good software practices such as decoupling, whether as part of building an application or performing integration. Modern integration patterns provide specialized, right-sized containers, offering improved agility, scalability and resilience, and look very different to the centralized ESB patterns of the past.
The rise of microservice architecture
Application servers reacted to the challenges of agility and scalability by introducing lightweight runtimes such as WebSphere Liberty profile, ideal for what is now commonly termed microservice architecture. These tiny footprint servers enable simple file systems based install, rapid deploy, start/stop in seconds and strong support for container based infrastructure.
Microservice architecture focuses on breaking siloed applications into small independent components which can then be changed independently, creating greater agility and independent elastic scalability. It enables them to make better use of cloud native infrastructure and be managed more ruthlessly, providing the resilience required by 24/7 online applications. It also improves ownership in line with DevOps practices whereby a team can truly take responsibility for a microservice component throughout its lifecycle.
Making use of “microservice principles” in integration
So if it makes sense to build applications in a more granular fashion, why shouldn’t we use those techniques in integration too? We could break up the enterprise-wide ESB component into smaller more manageable and dedicated pieces. Perhaps in some cases even down to one runtime for each interface we expose. This would make each individual integration easier to change independently and improve agility and scaling. Integration ownership could move to the business application teams that are directly focused on providing value add, streamlining the prioritization and implementation of new capabilities. The theory and background behind this idea is explored in a more detailed paper on “agile integration architecture”, but here we will explore a little more the changes IBM Integration Bus has been undergoing for some time now to meet these needs.
IBM Integration Bus – a lightweight integration runtime
If you’ve been keeping pace with IBM Integration Bus (IIB) you will know it has changed significantly since the days of the SOA. IIB now provides an extremely lightweight integration runtime with first class support for modern protocols such as REST and is well aligned with cloud native deployment needs. Let’s look at some specific examples;
- Fast, light integration runtime. The actual runtime for IIB has been slimmed down dramatically over the years. Installation is very straightforward and the runtime itself can now be stopped and started in seconds, yet none of its rich functionality has been sacrificed. It is totally reasonable to consider deploying a very small number of integrations to an IIB runtime and run them independently.
- Virtualisation and containerization. IIB runs in Docker containers, and has done for some time. We used Docker on the recent Redbook to make building the samples easier and faster.
- Stateless. IIB instances are stateless, and are not dependent on, or aware of one another. As such they can be added and taken away from a cluster freely and new versions of interfaces, or indeed the runtime itself, can run alongside one another for example for A/B testing.
- Distributed deploy ready. Run anywhere but monitor and manage in one place. IIB exports logs in standardized ways such that they can be gathered across multiple IIB instances and correlated with one another, and with other components in the invocation chain. There is out of the box ingestion into Bluemix based monitoring or you can use your own ELK stack or similar. We have other features too such as distributed business transaction monitoring, deep global cache support, and callable flows that further enable distributed deployments.
- DevOps tooling support. Continuous integration and deployment ready. Script and property file based install, build, deploy, and configuration to enable “infrastructure as code”. Installation automation via common tools, e.g. Chef, Puppet, IBM UrbanCode Deploy, embedded unit test automation and build/deploy automation with Ant, Git, and Jenkins.
- Cloud first. IIB on Cloud has been available as a managed cloud service for some time. We’ve recently introduced a standard IIB docker image to the Bluemix Containers service so you can start building your infrastructure in the cloud right away. Through the platform independence of containers, other PaaS vendors are also supported.
- JSON/REST support. Exposing REST and web services interfaces is a core capability for IIB. Interfaces can be directly defined within the tooling, or created based on pre-defined Swagger or WSDL definitions including key aspects of security. You can still use the powerful graphical data mapper even with schemaless JSON data.
- Current connectivity. IIB keeps pace with modern connectivity needs. It provides native connectivity to NoSQL databases such as MongoDb and Cloudant, messaging services such as Kafka, and SaaS (software as a service) applications such as Salesforce.
- File system based installation. Installation of IIB is now nothing more than placing binaries onto a filesystem and starting it up. Perfectly suited for the way images for containers such as Docker are created using layered filesystems.
So it is clear that IIB is completely comfortable as a minimal runtime in the cloud native space and ready for any form of lightweight runtime pattern.
How does this relate to ESB?
At this point it is worth reinforcing a key point. ESB is an architectural pattern. IIB is not an ESB, it is just a runtime specialized for integration. It can be deployed in a centralized ESB pattern if that suits your organization, but it is also well suited in a variety of other architectural patterns too, such as the one we describe here for decentralized “agile integration architecture”.
Benefiting from good design principles
Fine grained, well decoupled deployment of small integration components can be changed and scaled more independently, have tighter ownership, and are well suited to cloud native environments. Keep a close eye on this blog for more posts on how IIB enables the use of microservices design principles in integration.
Update: Since writing this blog post we have further explored this topic in a number of other posts. These are listed here: Agile integration architecture – useful links.
For details on our current thinking in this space and our future plans, we would encourage interested parties to sign up to the IIB vNext Early Access Program, and of course watch out for further posts and articles on this topic.