Tag: middleware

  • Red Hat Extends Runtimes Middleware Portfolio

    Red Hat Extends Runtimes Middleware Portfolio

    Red Hat has made available the latest instance of Red Hat Runtimes, a suite of lightweight open source components and frameworks that makes it easier to discover the middleware most appropriate for building a specific type of application.

    James Falkner, product marketing director for Runtimes at Red Hat, said as organizations embrace cloud-native application architectures based on microservices it’s become increasingly challenging to determine what middleware to deploy optimally and where. Red Hat Runtimes not only makes it easier to navigate all those options, Falkner said, but all the components and frameworks are certified to be pre-integrated.

    The latest version of Red Hat Runtimes adds support for Open Liberty, a lightweight runtime for building Java applications developed by IBM. Red Hat was acquired last year by IBM.

    The latest installment of Red Hat Runtimes also provides access to what has become a standard distribution of Node.js based on Red Hat Software Collections that will be implemented across all Red Hat offerings.

    Finally, Red Hat has also added support for Red Hat Single Sign-On, an access control framework based on the Keycloak project.

    Falkner said Red Hat Runtimes also serves to reduce the total cost by providing a single subscription through which organizations can access everything from container runtimes to the 3Scale application programming interface (API) management middleware, which Red Hat acquired in 2016.

    Very few IT organizations these days are standardized on a single class of middleware, especially as they embrace microservices-based applications built using containers. Most IT teams for the foreseeable future will need a flexible way to access multiple runtimes in support of everything from monolithic applications based on Java to applications built using Node.js code deployed using Docker containers.

    Rather than a piecemeal approach to the middleware infrastructure required to build, deploy and integrate all those applications, Falkner said Red Hat Runtimes provides a more holistic approach.

    It’s not clear how much or even whether IT organizations are centrally managing middleware in the age of DevOps and the cloud. Historically, many IT organizations preferred to standardize on a single application server platform to deploy various classes of middleware. However, many developers today are deciding what middleware to include within their application stacks without much input from a central IT function.

    Via Red Hat Runtimes, Red Hat is trying to make a case for providing developers with the flexibility they cherish in the form of a subscription service that provides IT teams with a modicum of control over what middleware gets employed.

    Tensions between DevOps teams and central IT organizations have arguably never been higher. In fact, many DevOps teams are operating within lines of business that are outside the direct control of centralized IT. As such, the level of standardization that can be imposed by central IT organizations has become more constrained. Many centralized IT organizations are now trying to influence middleware platform decisions rather than outright make decrees that might get ignored anyway.

    Regardless of the middleware platform choice that ultimately gets made, however, the one thing that most centralized IT teams will have to come to terms with is finding a way to support it.

    — Mike Vizard

  • More App Dev Models Increase DevOps Pressure

    More App Dev Models Increase DevOps Pressure

    A bifurcation in types of developers will become more pronounced in the years ahead as more application code moves to the network edge. As that transition continues occurring, the pressure on IT operations to be able to be able to flexibly manage different classes of applications by embracing DevOps processes will correspondingly increase.

    Mike Piech, vice president and general manager of middleware for Red Hat, said applications running on internet of things (IoT) devices and smartphones present developers with a finite amount of compute resources that require them to have advanced skills. Conversely, back-end applications can now take advantage of multiple layers of abstraction, including (soon) serverless computing frameworks based on event-driven architectures that make potentially unlimited compute resources available. The availability of all those compute resources, however, encourages developers of back-end services and applications to be less disciplined when writing applications.

    The good news is that it’s getting easier to right-size applications using trial and error methods versus having to commit to a specific computing architecture up front, said Piech. If something doesn’t work as well as it should, modular approaches to microservices make it possible to more easily move application code to where it should best optimally reside. Rather than focusing on the rigor of the underlying architecture, developers are free to experiment with different tools and languages more now than any time in the history of IT, he said.

    In fact, Piech speculated that many graphical user interfaces will continue to run locally while accessing a wide variety of back-end services via application programming interfaces (APIs). That approach essentially creates a new form of hybrid computing wherein developers no longer need to think much about the runtime environment, he noted.

    However, all that freedom tends to put a lot more pressure on the IT operations team. As the types and classes of applications continues to evolve, Piech said it’s only a matter of time before more organizations move further down the DevOps path. Adoption of DevOps processes across organizations has been somewhat uneven. But as developers experiment with different computing models, the expectation is that operating teams will be flexible enough to dynamically make the appropriate adjustments, he said.

    Longer term, middleware and databases will eventually be deconstructed into sets of microservices that developers can call when needed. Today, IT operations teams make available monolithic application servers and databases. Many of those databases and application servers are starting to be encapsulated in Docker containers as part of a first step toward lifting and shifting applications into the cloud before transitioning to more agile microservices-based frameworks, Piech said.

    In some cases, those services will be accessed directly via a platform-as-a-service (PaaS) environment or a serverless computing framework. Piech said Red Hat expects serverless computing frameworks based on event-driven architectures will be used mainly to provide bursting capabilities as a complement to long-running stateful applications that typically consume a fixed amount of IT infrastructure resources. It’s probable stateless applications that run intermittently also will find their way on to serverless computing frameworks. Red Hat has thrown its support behind the open source OpenWhisk serverless computing framework.

    There clearly will be many more types of distributed applications running across the enterprise. IT operations teams may not have much control over what types of applications run where and when. But they will be expected to be able to deploy and manage them all, regardless.

    — Mike Vizard

  • The role of middleware in DevOps

    The role of middleware in DevOps

    Middleware has a very important and strategic role in DevOps, according to Ben Henshall, middleware business unit manager at Red Hat Australia and New Zealand. ‘Rapid everything’ is part of DevOps culture, so the bloated, proprietary middleware with roots in the late 1990s and early 2000s – the pre-cloud era – is a poor fit.

    He pointed to an unnamed government organization that is limited to two major code releases per year, largely because of the complexity of its middleware and associated processes, which means systems have to be brought down completely for a weekend to deploy the updates.

    This is in stark contrast with current thinking, and Henshall pointed to the frequently-cited 2009 presentation by John Allspaw and Paul Hammond http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr that described how Flickr managed 10 full deployments during a typical day.

    Modern middleware is designed with cloud deployments in mind, including a multitenant architecture and a small resource footprint that minimizes infrastructure requirements. The best examples are based on Open Source projects with many contributors and extensive testing, and are developed and tested in the cloud, said Henshall, presumably with Red Hat JBoss Enterprise Middleware in mind.

    It may be necessary to re-architect applications in order to decouple them from old-school middleware so a more modern replacement can be used, but technologies such as containerization can simplify the task, he suggested. While the right middleware and the adoption of Platform as a Service (PaaS) help – along with technologies such as OSGi (Open Service Gateway Initiative, which allows updated Java code to be deployed without stopping and restarting a system, among other things) as implemented in Apache Karaf (which is part of Red Hat JBoss) – but it is important to design applications so they can be maintained without outages, he said.

    PaaS has seen a rapid rise in popularity as it makes it easier for developers to build and test new logic, and for operations staff to manage multiple systems without customization and with the benefits of automated releases. For example, Cisco has released more than 240 applications in around 12 months by using Red Hat OpenShift PaaS, said Henshall, noting that it can run on premises or be consumed as a service run by Red Hat.

    The automation provided by PaaS fits in with the operations goal of running stable, reliable and secure systems, while reducing the need for “operations ninjas” who are potential single points of failure in the event of illness or resignation.

    Henshall said OpenShift customers include a tertiary education institution that adopted OpenShift to speed the development and deployment of new applications and can now provision new systems within minutes, a software vendor that has reduced the time to market for new initiatives, and a major Commonwealth Government department that has been able to meet internal requirements concerning security, supportability and risk reduction since adopting the PaaS.

    Being able to support innovation in the shortest time and with the least risk “is such a huge thing” for organizations, he said, especially when it can be combined with dramatic costs reductions and easier compliance.

    Vendors such as Red Had provide products and services to support the DevOps culture, he said, noting “our software is developed by people facing these issues.”

    About the Author/Stephen Withers

    stephenWithers

    Stephen Withers is one of Australia¹s most experienced IT journalists, covering everything from gadgets to enterprise systems. In previous lives he has been an academic, a systems programmer, an IT support manager, and an online services manager. Stephen holds an honours degree in Management Sciences, a PhD in Industrial and Business Studies, and is a senior member of the Australian Computer Society. You can see his Linkedin profile here: http://au.linkedin.com/pub/stephen-withers/0/222/687/