“You don’t need to focus on technology. You need to empower your developers.”
There are certain patterns in the middleware / application development tracks for Red Hat Summit this year, and they revolve a lot around microservices. That makes a certain kind of sense (microservices are the new hotness in app development), but it’s also reflective of a larger current in technology, a continuing push toward … something.
In his opening keynote, Red Hat EVP Paul Cormier noted that one of the themes of Summit 2016 was “dev and ops coming together through common architectures, processes, and platforms.” This echoes major trends in technology — DevOps and architectures, process, and platform as a unifying IT strategy — and yet none of these concepts are really new. Two decades ago, there were developers and operations, there was enterprise architecture, application platforms, and internal processes. So what’s new and what is bringing the urgency now?
I think the difference comes down to speed (and eventually differences in degree become differences in kind). Twenty years ago, an application was released yearly, sometimes even every couple of years. A patch or security update could take a few months to move in the pipeline from development to testing to production.
Now customers expect patches for security vulnerabilities within hours of them being detected, and the expanding number of applications (from consumer mobile apps to internal systems to IoT devices) means that enterprises have potentially dozens of touchpoints and hundreds of services to maintain.
The “modern” part of modern application development isn’t in the app — it’s in the speed.
This year’s Summit kicked off with three interlocking demos, each showing the different paths and progressions that an IT environment will face as they juggle modernizing existing applications and creating new ones within a heterogeneous (and dynamically changing) ecosystem.
Lifting and Shifting (Windup)
James Falkner, running the Windup tool live
Windup has been around for a few years as a community project, but it’s only recently been available as a supported and test tool (Migration Toolkit) from Red Hat. The concept is pretty simple — you feed an app into Windup at one end, it flags any potential configuration issues, and then it exports it into a JBoss EAP instance at the other end.
In the first demo on Tuesday, James Falkner (technical marketing manager for EAP) made it look just that easy. He took his legacy, monolithic Java EE app, ran the Windup tool, identified and changed some configuration with a point-and-click UI, and then moved the application into a JBoss EAP instance running in an OpenShift container.
This approach is called lift and shift (or to sound a little nicer, rehosting) since it takes an app and just moves it to a new infrastructure with minimal changes. This is also a common first step to app modenrization.
Cloud Ready to Cloud Native (OpenShift.io)
In his initial keynote, Paul Cormier said that there was an important difference between cloud ready and cloud native. Cloud ready just meant that something was able to run in a cloud — cloud native means that it was designed and written to operate in a cloud.
The second big demo, by Todd Mancini, looked at a new development tool that is in the cloud: OpenShift.io. The tagline is that this is “an end to end development tool for the cloud,” which is a little clunky, but it hits on the fact that this tool actually runs in a cloud to develop apps for the cloud. It includes an IDE, it offers a variety of different runtimes and languages, and it can build any app and then deploy it to a container. It even includes CI/CD pipelines.
The outcome is applications that are entirely developed, built, and deployed in a cloud — truly cloud native applications.
Todd created and deployed a new app within OpenShift.io — but running in the same environment was the legacy app that James Falkner had migrated during his Windup demo. It was kind of a “blink and you missed it” moment, but it was a very cool moment for anyone who has an existing application environment — you can unite legacy and new development seamlessly and create a better experience for developers.
Todd Mancini, looking at the new app in OpenShift.io
Managing Your Services (iPaaS)
After the first two demos, the environment hosted two apps: the migrated legacy app and the new cloud-native app. They were in the same OpenShift environment, but that was it. The third demo integrated the two applications, using a hosted integration platform as a service (iPaaS).
Keith Babo started off with a 3scale demo, looking at the APIs and consumption patterns for the environment. Doing this kind of evaluation lets you see what functionality is more relevant to users and the patterns that they engage with different aspects of the API. Since the API definitions and the API policies are independent in 3scale, you can be flexible in what parts of the APIs are exposed and to what users or services.
Keith Babo, evaluating the API usage trends over the course of the morning in the 3scale API Management Platform UI
Taking a step back, in distributed systems like microservices, there are generally two ways that the services are connected together: messaging and API management. While you can do one or the other, in a lot of environments, it makes sense to do both and to focus on different strengths in both. Something like Fuse (combined with the messaging of AMQ) manages and converts the data between applications or external clients, while 3scale defines and manages the APIs and policies between services. It’s all integration, just integrating different perspectives of the infrastructure and applications.
The last part of the demo was a surprise example of a project called Syndesis. Red Hat Fuse is based on Apache Camel, which defines enterprise integration patterns in a programmatic and consumable way. But there’s not a clear UI or management component to Camel — its focus is for developers and it offers them the flexibility to develop in the language that they like. But the logic behind integration is a business and analytics strategy, not a development one. Syndesis creates an extremely simple and clear visual representation of the underlying data, attributes, and applications within the integration environment. This is “low code” development, because a business analyst can just log in and define data mapping or integration patterns between applications with a few clicks.
Mapping data attributes between services in iPaaS / Syndesis
Technology is and isn’t the focus
So I started with a quote about how technology isn’t the goal and then proceeded to detail three technology demos. And, yes, they are about technology, but (to steal a line from a later keynote), the focus isn’t technology itself. The focus is on behavior, on usage, on how people interact or want to interact with systems. Technology is simply a means; people define the ends. These tools empower the developer, either by allowing them to simply and increase what they can do with older systems and new projects or by turning people into developers who never would be otherwise.