Red Hat OpenShift Application Runtimes + JBoss EAP for fast, lightweight, Java EE cloud applications

Have you read the announcement of the alpha release of Red Hat OpenShift Application Runtimes (RHOAR)? We also posted an introduction to the component in RHOAR earlier.

Red Hat Intends to include entitlements for the JBoss Enterprise Application Platform (EAP) as part of a Red Hat OpenShift Application Runtimes (RHOAR) subscription.  The reasoning for this is dead simple, there is still strong demand for a Java application platform the implements the Java EE specification. JBoss EAP 7 fits that requirements with certified full platform and web profile support for the Java EE 7 specification. Best of all, JBoss EAP offers Java EE 7 capabilities in a small, fast, cloud ready footprint. It has been available on the OpenShift Cloud Platform (OCP) since version 6. JBoss EAP is cloud ready and deserves to be included as a RHOAR component.

I want to believe. Prove that JBoss is small and fast!

First lets agree on what a Java EE application platform is. I propose a minimalist definition. That being, a Java EE application platform is verified to have implemented a specific Java EE specification. The current Java EE 7 specification is extensive and runs 290 pages long. Implementing the details is no trivial task. As of the date of this article, there are eight products that have been verified by Oracle to be Java EE 7 full platform compatible implementations. Red Hat JBoss EAP 7 is one of those products. However, Apache Tomcat, JBoss Web Server, and Pivotal tcServer are not on the list. Those products are not Java EE application platforms.

Continue reading “Red Hat OpenShift Application Runtimes + JBoss EAP for fast, lightweight, Java EE cloud applications”

Eclipse MicroProfile continues its growth in the market

Organizations that have already embarked or are thinking about starting a digital transformation journey are assessing and looking for ways to leverage their Java EE expertise. IT development and operations have built Java expertise over years, and there is a challenge to balance their existing skill base with new digitally transformative technologies, such as microservices, APIs, container-based architectures, and reactive programming. Eclipse MicroProfile is an open source project and one of those digitally transformative technologies that enables and optimizes the development of microservices — using familiar Java EE technologies and APIs.

You can think of MicroProfile as minimal standard profile for Java microservices. As with Java EE, MicroProfile implementations across different vendors are fully interoperable.

MicroProfile is supported in WildFly Swarm on the recently announced Red Hat OpenShift Application Runtimes, our polyglot runtime platform powered by OpenShift, Kubernetes, and OpenStack. This delivers on the goal of simplifying the inherent complexity of developing cloud native applications.

There are a lot of reasons to begin adopting MicroProfile:

  • Open source, of course
  • Agility in developing microservices
  • Ability to leverage innovation
  • Architectural interoperability across different vendor offerings
  • No vendor lock-in
  • Fast learning curve for Java EE users (Java EE users can leverage their knowledge when using MicroProfile)
  • Ability to run on Red Hat OpenShift Application Runtimes 

Since MicroProfile was announced in June 2016, a lot has happened.  MicroProfile v 1.0 was released on September 19, 2016. Its implementation interoperability was demonstrated on November 2016 at Devoxx, where Red Hat, IBM, Tomitribe, and Payara demoed a unified web application with underlying microservices which had been developed separately by each vendor using MicroProfile. In addition, MicroProfile became part of the Eclipse Foundation as an incubation project back in December 14, 2016. New members have joined MicroProfile, such as SOUJava, Hazelcast, Fujitsu, Hammock, and kumuluzEE (the complete list of members can be found here).

Future releases of MicroProfile will build upon the existing foundation with organic growth by adding configuration, security, health check, and fault tolerance APIs, as well as adding support for later versions of CDI, JAX-RS, and JSON-P. The MicroProfile open source project plans to put out releases on an agile schedule and based on feedback from the open source community, which is accessible to everyone. Join the conversation and check out the MicroProfile site.

Announcing the Alpha release of Red Hat OpenShift Application Runtimes

Today Red Hat announced the alpha release of Red Hat OpenShift Application Runtimes (RHOAR). This is the first of many articles on the subject that will be published on the JBoss Middleware blog.

So what is RHOAR?

RHOAR provides application developers with a variety of application runtimes running on the OpenShift Container Platform. Specifically, the following application runtimes will be included in RHOAR:

  • Red Hat JBoss Enterprise Application Platform (EAP) – existing Java EE / Spring apps.
  • WildFly Swarm running MicroProfile – Java EE centric MSA
  • Spring Boot / Cloud – Spring centric MSA
  • Vert.x – greenfield reactive Java
  • Node.js – greenfield reactive JavaScript

Continue reading “Announcing the Alpha release of Red Hat OpenShift Application Runtimes”

Red Hat Summit 2017 – Planning your JBoss labs

This year in Boston, MA you can attend the Red Hat Summit 2017, the event to get your updates on open source technologies and meet with all the experts you follow throughout the year.

It’s taking place from May 2-4 and is full of interesting sessions, keynotes, and labs.

This year I was part of the process of selecting the labs you are going to experience at Red Hat Summit and wanted to share here some to help you plan your JBoss labs experience. These labs are for you to spend time with the experts who will teach you hands-on how to get the most out of your JBoss middleware products.

Each lab is a 2-hour session, so planning is essential to getting the most out of your days at Red Hat Summit.

As you might be struggling to find and plan your sessions together with some lab time, here is an overview of the labs you can find in the session catalog for exact room and times. Each entry includes the lab number, title, abstract, instructors and is linked to the session catalog entry:

Continue reading “Red Hat Summit 2017 – Planning your JBoss labs”

Architecture, Process, Platform

Digital transformation is a hot topic in enterprises these days, and like any such topic it’s associated with a wide range of use, overuse, and misuse. But the phrase does get at something that we can all sense is really going on, a truly profound change. As different businesses undergo or undertake variants of digital transformation, we see a number of common characteristics of the more digital world:

  • More things happen (or are expected to happen) in real time
  • More different sources and kinds of data are brought together
  • Activities are more decentralized and ad hoc
  • There is a broadening of participation in both the building and the use of I.T.
  • There is a shift from analysis and planning to trial-and-error experimentation

Each of those ideas deserves elaboration–topics for future blogs–but going for the moment with whatever came to mind for those bullets as a rough characterization of digital transformation, let’s explore the interplay of architecture, process, and platform in helping enterprises compete and succeed in this emerging digital world.

Continue reading “Architecture, Process, Platform”

It’s Official: MicroProfile Is Now Eclipse MicroProfile

MicroProfile is a community project with the mission of optimizing Enterprise Java for a microservices architecture.  In a short period of time, MicroProfile has reached three important milestones:

  1. June 27, 2016: Red Hat, IBM, Tomitribe, Payara and the London Java Community announced MicroProfile at DevNation.
  2. September 19, 2016: MicroProfile 1.0 was released at JavaOne 2016 with 5 implementations (and a 6th planned). The SouJava community joined to support the effort and Hammock was added as a implementation.
  3. December 14, 2016: The Eclipse Foundation Board approved the MicroProfile proposal, meaning that Eclipse MicroProfile is now an Eclipse incubator project. Mike Milinkovich, Eclipse Foundation Executive Director,  informed the community shortly after the vote.

The community is having active discussions on process (project evolution) and microservice APIs like application configuration, monitoring, health check, messaging, circuit breakers, and more.  Some discussions are even backed by real (proof of concept) code! The MicroProfile community is currently planning its next release. Feel free to join the discussion and help define the future of Enterprise Java microservices!

It’s a great Red Hat day in Minneapolis — Go Microservices !

Cross posted from the Red Hat Events Blog.

It was a great day in Minneapolis! The Microservices with Apache Camel was held at Target Field (inside the ballpark, overlooking the field of play). “Takes a lot to put together an event like this but can certainly be a lot of fun! Go microservices!,” says Red Hat associate Jen Fissel.

1-jen-fissel
Jen Fissel

I had the privilege of hosting the event and kicked off the event with a reference to the connected world we live in that requires enterprises to be agile while being integrated across the systems of yesterday with the evolving applications of the future. The future of Enterprise IT, containers, are here today and microservices are the stars of the show. Welcome to Minneapolis!

Continue reading “It’s a great Red Hat day in Minneapolis — Go Microservices !”

New styles of integration are the hallmark of Digital Transformation

New Styles of Integration 2

Shakeup your integration strategy to enable digital transformation, says VP & Gartner Fellow Massimo Pezzini. Pezzini asserts that it is not just about transforming and modernizing the infrastructure and the applications concerned.  Some of the fundamental concepts of integration need to be revisited and transformed as well.  Such systemic transformation punctuate the migration of  legacy environments to microservices and the cloud.  What may have worked in the past will no longer be applicable going forward.  “Integration is dead.  Long live integration,” screamed the title of one of the sessions at the Red Hat Summit 2016.  The session was making a point.  Integration, as we knew it a few years back, is dead.  Integration in the digital world has a long life in the decades ahead.  Join me as I walk through the new styles of integration that are the hallmark of digital transformation.

Continue reading “New styles of integration are the hallmark of Digital Transformation”

Visualizing Integration Applications

Since I’ve changed roles and started performing architect duties, I have to draw more boxes and arrows than write code. There are ways to fight that, like contributing to open source projects during sleepless nights, POCs, demos, but drawing boxes to express architectures and designs is still big part of it. This post is about visualizing distributed messaging, SOA, microservices applications in agile environments (this term has lost its meaning, but there is not better one in this case). What I like about the software industry in recent years is that the majority of organizations I’ve worked with value the principles behind lean and agile software development methodologies. As long as it is practical, everyone strives to deliver working software (rather than documentation), deliver fast (rather than plan for a long time), eliminate waste, and respond to change. And there are management practices such as scrum and kanban, and technical practices from extreme programming (XP) methodology such as unit testing, pair programing, and other practices such as CI/CD and DevOps to help implement those principles. In this line of thinking, I decided to put together a summary of the design tools and diagrams I find useful in my day to day job while working with distributed systems.

Issues with 4+1 View Model and Death by UML

Every project kicks off with big ambitions, but there is never enough time to do things perfectly, and at the end we have to deliver whatever works. And that is a good thing, it is the way the environment helps us avoid gold plating and supports principles like YAGNI and KISS, so we do just enough and adapt to changes.

Looking back, I can say that most of the diagrams I’ve seen around are inspired by the 4+1 view model of Philippe Kruchten which has logical, development, process and physical views.

4+1_Architectural_View_Model
4+1 View Model.  From A Practical Guide to Enterprise Architecture by James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, Elias K. Jo, 2003.

I quite like the ideas and the motivation behind this framework: using separate views and perspectives to address specific set of constraints and targeting the different stakeholders. That is a great way of describing complex software architectures. But I have two issues with using this model for integration applications.

Diagram Applicability

Typically these views are expressed through a unified modeling language (UML), and for each view, you have to use one or more UML diagrams. If I have to use 15 types of UML diagrams to communicate and express a system architecture in an accessible way, it defeats the purpose of UML.

Death by UML
Death by UML. From Wikipedia, derived from a diagram by Paulo Merson.

With such a complexity, the chances are that there are only one or two people in the whole organization who have the tools to create and ability to understand and maintain these diagrams. And having hard-to-interpret, out-of-date diagrams is as useful as having out-of-date documentation. These diagrams are too complex and with limited value, and very quickly they turn into a liability that you have to maintain rather than an asset expressing the state of a constantly changing system.
Another big drawback is that the existing UML diagram types are primarily focused on describing object-oriented architectures rather than pipes and filters architectures. The essence of messaging applications is around interaction styles, routing, and data flow rather than structure. Class, object, component, package, and other diagrams are of less value for describing pipes and filters based processing flows. Behavioral UML diagrams such as activity and sequence get closer, but still cannot express easily concepts such filtering and content based routing, which are a fundamental part of integration applications.

View Applicability

Having a different set of views for a system to address different concerns is a great way of expressing intent. But the existing views of the 4+1 model don’t reflect the way we develop and deploy software nowadays. The idea of that directional flow — that you have a logical view first, which then leads to development and process views, and those lead to a physical view — is not always the case. The systems development life cycle is not following the traditional (waterfall) sequence of requirement gathering, designing, implementing, and maintaining.

2000px-CPT-SystemLifeSycle.svg
Software Development Lifecycle. Derived from an image by Web Serv

Instead other development methodologies such as agile, prototyping, synchronize and stabilize, and spike and stabilize are used too. In addition to the process, the stakeholders are changing too. With practices such as DevOps, developers have to know about the final physical deployment model and the operations team have to know about the application processing flows.

Modern architectures such as microservices affect the views too. Knowing one microservice in a plethora of services is not very useful. Knowing too much about all the services is not practical either. Having the right abstraction level to have a system wide view with just enough details becomes vital.

Practical Visualization for Integration Applications

The closest thing that has been working for me is described by Simon Brown as the C4 model. (You should also get a free copy of Simon’s awesome The Art of Visualising Software Architecture book). In his model, Simon is talking about the importance of a common set of abstractions rather than common notation (such as UML) and then using simple set of diagrams for different level of abstractions: system context, container, componentand class. I quite like this “outside-in” approach, where you first have 10000 foot view and with each next level, going deeper with more detailed views.
C4 is also not an exact match for middleware/integration applications either, but it is getting closer. If we were to use the C4 model, then the system context diagram would be one box that says ESB (or middleware, MOM, or microservices) with tens of arrows from north to south. Not very useful. The container diagram is quite close, but the term container is so overloaded (VM, application container, docker container) which makes it less useful for communication. Component and class diagrams are also not a good fit as pipes and filter architectures are focused around enterprise integration patterns, rather than classes and packages.
So at the end, what is it that worked for me? It is the following three types of diagrams which abbreviate as SSD (not as cool as C4):  system context, service design, and deployment.

System Context Diagram

The aim of this model is to show all the services (whether they are SOA or microservices) with their inputs and outputs, ideally having the external systems on the north, the services in the middle section, and internal services in the south. Or you could use both external and internal services on both side of the middleware layer as shown below. Also having the protocol (such as HTTP, JMS, file) on the arrows, with the data format (XML, JSON, CSV) gives useful context too, but it is not mandatory. If there are too many services, you can leave the protocol and the data format for the service level diagrams. I use the direction of the arrow to indicate which service is initiating the call rather than the data flow direction.

System Context Diagram
System Context Diagram

Having such a diagram gives a good overview of the scope of a distributed system. We can see all the services, the internal and external dependencies, the types of interaction (with protocol and data format), and the call initiator.

Service Design Diagram

The aim of this diagram is to show what is going on in each box representing a middleware service from the system context diagram. And the best diagram for this is to use EIP icons and connect those as message flows. A service may have a number of flows, support a number of protocols, implement real time, or batch behaviour.

Service Design Diagram
Service Design Diagram

At this level, we want to show all possible data flows implemented by a specific service, from any source to any destination.

Deployment Diagram

The previous two diagrams are the logical views of the system as a whole and each service separately. With the deployment diagram, we want to show where each service is going to be deployed. Maybe there will be multiple instances of the same service running on multiple hosts. Maybe some services will be active on one host, and passive on the other. Maybe there will be a load balancer fronting the services.

Deployment Diagram
Deployment Diagram

The deployment diagram is supposed to show how individual services and the system as a whole relates to the host systems (regardless whether that is physical or virtual).

What Tools Do I Use?

The system context and the deployment diagrams are composed only of boxes and arrows and do not require any special tools. For the service design diagram, you will need a tool that has the enterprise integration pattern icons installed. So far, I have seen the following tools with EIP icon support:

Other development tools that could be also used for creating EIP diagrams are:

A system context diagram is useful to show the system wide scope and reach of the services, a service design diagram is good for describing what a service does, and a deployment diagram is useful mapping all that into something physical.

In IT, we can expand work and fill up all the available time with things to do. I’m sure given more time, we can invent ten more useful views. But without those basic three, I cannot imagine describing an integration application. As Antoine de Saint-Exupery put it long ago: “Perfection is finally attained not when there is no longer anything to add but when there is no longer anything to take away.

Mike Piech and Rich Sharples on Facebook LIVE from Red Hat Summit

Rich Sharples, senior director of product management, and Mike Piech, vice president of marketing, got together for a half hour at the end of the Summit day today to discuss some of the major issues that have come out related to middleware this week. There have been some major announcements: the new microprofile project, the release of Red Hat JBoss EAP 7, the growth of microservices, and the recent acquisition of 3scale and what that means for API management in Red Hat Middleware.

As a quick summary, two of the major themes underscoring a lot of the announcements around JBoss, middleware, and Java this week relate to things that are micro: microservices and microprofile.

Microservices has been a subtext in many of the JBoss EAP 7 sessions and in the OpenShift sessions because this containerized, immutable, consistent environment is what makes microservices possible.Containers fundamentally enable microservices. You have an underlying runtime that is commensurate with the idea of “micro.” You can scale elastically, add instances to scale up and down. The opportunity to change things as an application travels from the desktop to the data center is much less. These are communicating systems, and that’s what container orchestration is. It coordinates these complex webs. we’re The application is the only thing that matters. Operations is there to support the application. I hit a build button and it goes through my CI/CD system, and it’s the same configuration in the environment.

However, like any application or project architecture, it’s more than “JBoss + OpenShift  = awesome microservices.” There has to be consideration and weight given to the application and the underlying technology to find a structure that fits. Microservices architecture isn’t about taking everything you’ve got and decomposing it into atomic services. It’s about having a range of sizes and services, depending on what you need. It is important to be conscious of the trade-offs that come from the increased complexity of the system. It really depends on the organization and the technology platforms they have what architecture is appropriate.

That need to understand and define the underlying framework to do microservices effectively is the theme of the second topic: the microprofile. There are defined specifications for different Java platforms (Standard and Enterprise) but both have the assumption of large-scale, full server architectures. New wave development, though, is increasingly small, with small services in those larger complex systems. What Java EE introduced to development was consistency and dependability. As we move into a new containerized world, we must do it responsibly, preserving the consistency and stability of previous environments. The microprofile project was created because a lot of vendors – Red Hat, IBM. Tomitribe, Payara – were just on a Slack chat, discussing what they needed to do for microservices and ways they could implement it. And then there was a lightbulb: maybe there’s something here. This is a chance to bring the whole Java community around a new architecture, with the strengths and discipline they’ve already developed.

Watch the whole video. For microprofile, you can join the Google group or check out the microprofile site for more information and emerging discussions.