luchschen_shutter - Fotolia
Introducing microservices, containers and cloud services to your enterprise architecture? Then, consider using automated middleware software and services, which can be like an air traffic control system for your middleware stack, said Java architect Calvin Martin, manager of product development for BMC Software in Houston.
Middleware consists of software and services that live between applications and operating systems that provide the connecting fabric. Middleware automation lets developers bypass the traditional manual tasks, like scripting, involved in managing deployment of middleware software suites like IBM WebSphere, Red Hat's JBoss, Apache Tomcat and others.
Today, an application server, which provides the business logic for an application, can have as many as 35,000 configuration items on it, Martin explained. "Managing those configurations is like flying an airplane, where you have a bunch of switches that you can change. If you change something incorrectly, then you risk making your application crash or fail in production."
In this Q&A, middleware software experts Martin and his BMC cohort, Akbar Aziz, explain what middleware automation is and how it can be used. Aziz is BMC's lead product manager for server automation and was previously responsible for infrastructure and support for the corporate websites for JPMorgan/Chase. Before joining BMC, Martin's positions included software developer and Java architect for several Fortune 2000 firms. They both work on the BMC Middleware Automation tool suite, but this interview concerns middleware software and automation trends and not that product line.
What are the benefits of middleware automation?
Akbar Aziz: Middleware automation allows developers and architects to connect to these various types of middleware to perform things like backups, snapshotting, release, upgrades. Automating middleware also helps businesses get fast reports on application performance, so they can make quick decisions about expanding production or rolling the app back.
Calvin Martin: Automating the middleware stack could help DevOps managers ensure that configuration and application deployments occur as intended in the selected environment. Add new functionality into production, you would be fully aware of what is going to change before you actually go and change it, and then you can actually implement that change.
What bottlenecks in middleware software management led to the need for automating middleware?
Martin: One example is configuration management, because people often do one-time changes in production and forget about those changes. Then, months later they realize there's a problem with the changes that actually were implemented in the first place, [but] they have no recollection of why the change was there or done. So, automation is a tool that would be useful for enabling people to become more agile, but not at the risk of actually introducing more risk to the application, whether it's security-based or not.
As companies decide that they want to move their applications into a different area, such as in the cloud or in a Docker container, then this is where middleware automation would come in handy.
Calvin, earlier you mentioned application server management. Could you explain where those app servers may live?
Martin: The target environment is an application server, which can be on premises or in the cloud. When managing application server configurations, automation provides the opportunity to introduce something that is repeatable, and repeatable processes reduce human error.
How does introducing containers into an enterprise IT environment affect middleware practices?
Martin: I see more and more customers being able to increase application development by getting onto a container environment or container infrastructure. A Docker container, for example, encapsulates the application and provides a lot of flexibility, but there's still a need for middleware management. Although you have containers or images that basically represent the application in a static state, there's still the need with containers to use middleware services that propagate that configuration, regardless of containerization of applications.
Containers provide a very flexible environment for development teams and one of the biggest problems when developing applications is that you're worried about the environment where you're at, and there's clashes and collisions of different libraries that are needed in order to support your particular application.
Where's the value in middleware automation when microservices are introduced?
Martin: So, let's create microservices and put these microservices inside of a container, so that they're self-contained. You don't have to worry about dependencies or libraries or any clashes or anything like that. That's a good thing, and people will take advantage of it. They will create a lot of microservices. Managing those microservices will become a challenge, and no company can hire enough people to do this manually.
Would there be any difference in use of middleware automation in a microservices architecture versus an SOA architecture?
Martin: Well, the underlying joke is that the only reason we use the term microservice is because people don't want to get fired for saying SOA. SOA is a service-based architecture. So is a microservice-based architecture. One could say that microservices is more of a pragmatic approach to SOA. That's basically all it is.
Addressing security threats from middleware tools
Mapping out automation strategies
How to use the cloud to bridge systems