In case you missed it, there is an infographic based on research from IDC that IDC and Red Hat released (executive summary), nicely illustrating the business value of Red Hat JBoss Enterprise Application Platform 6.
If all men were angels, no government would be necessary.
James Madison made the case that no system is perfect precisely because people aren’t perfect. That was, admittedly, a defense of a political revolutionary moment, but it holds true in software design as well.
Mark Little, vice president of engineering for middleware at Red Hat, has a blog post on this topic this week on jboss.org. The entire post is terrific (and readably brief), but there are a couple of points worth highlighting. His premise starts with the idea of what causes (or devolves) a system into a monolith, and he points to this:
Lack of architect (leadership); the original architect(s) leave the project and those who come in to replace them (if they are replaced) can’t control the developers or perhaps don’t understand the architecture enough to ensure it remains “pure”. Likewise, different developers coming into the project to either add to or replace those there already, can dilute the group knowledge and understanding of the architecture, leading to unforeseen and accidental divergence from the original plan.
What leads to an inflexible, centralized monolith application is, ironically, a lack of central vision. Mark sums it up with a really good point about the risks in microservice architectures:
I believe in and understand the need for distributed systems composed of (micro) services. However, what worries me about some of the current emphasis around microservices is that somehow they will naturally result in a better architecture. That’s simply not the case. If you don’t put in to place the right processes, design reviews, architecture reviews, architects etc. to prevent or forestall a local monolith then you’ve no hope of achieving a good microservices architecture. [emphasis added]
This is such an amazing point, it bears repeating. There is frequently this unspoken, sometimes unrecognized, belief that The Next Good Thing will some how solve all of the issues of the Last Good Thing without requiring special effort. But there are no perfect systems — clear planning, good communication, good team processes are required no matter what architectural pattern you’re using to develop your applications.
The story of Wildfly Swarm, from a business perspective, is kind of a story of microservices. Microservices are small, isolated, and focused service applications; as an architecture, microservices is an approach that decomposes larger systems into those smaller, focused, isolated services. These services talk to each other through a shared, common API, but are otherwise independent in design and deployment. Microservices, then, are frequently aligned with DevOps – which uses small, agile teams to quickly develop and push software for continuous integration (of systems) and continuous delivery (of software).
But what is Wildfly Swarm, in that context.
An increasingly common buzzword in cloud computing is microservices. Like a lot of things associated with cloud technologies, a precise definition is difficult to find — and it can mean a lot of things to a lot of different people, depending on the context. Since this is a blog devoted to middleware issues, I want to define microservices within the context of that middle layer in computing, for application development.
Microservices is an architectural approach for a software system. Meaning, it defines how individual services fit together and how those services are constructed (like, general constraints or best practices). What sets microservices apart from other architectural approaches is that it treats each service as a discrete and independent part of the architecture. That means that services themselves (within that system) have very clear definitions:
Part 1 looks at a handful of business considerations that you need to account for when you’re looking at Java EE application platforms — but that is only a part of selecting anything for your IT environment. In addition to treating an IT decision as a capital asset, your planning has to include technical factors: current and future development models, different types of applications, even rapid data processing.
Success today depends on achieving high levels of agility and flexibility. Major technology trends like mobile, the Internet of Things, and big data rely on lightweight, iterative environments like virtualization, cloud, and containers. This is forcing organizations to rethink their application development and deployment processes, application architecture designs, and choice of technologies used to build and run applications.
Historically, choosing a Java EE application platform was like any major capital planning — it was driven by a clear business logic:
- Support for your current platform was expiring.
- You had to standardize your systems.
- You needed to accommodate a legacy system.
- You needed to reduce costs.
- You needed to take advantage of a specific advancement in Java technology.
Those are still primary factors, but there are a lot of additional factors to consider for something as foundational as an application platform. Part one of this series covers the business questions; part 2 will be out later this week to look at some of the technical considerations. [UPDATE: Part 2 is now live.]
Business considerations have a significant role in IT decision-making because your partnerships and budget commitments directly impact your company’s development agility, ability to adopt new technologies, and internal and external design decisions. When you start weighing your options, aside from transaction costs, there are a handful of questions you must ask to make sure that you maintain business agility.
As discussed in our previous post, healthcare companies face many integration challenges: complex data standards like HIPAA and HL7, differences in applications across the healthcare industry, and increasing regulations about meaningful use and value-based care.
These challenges are compounded by legacy technologies. Many healthcare companies’ internal enterprise applications were set up years ago using various data formats that cannot directly interoperate with one another. One way to solve this problem was to turn to enterprise service buses (ESBs) to transform and normalize data across different applications for cross-company communications, and a popular system was Java Composite Application Platform Suite (JCAPS). JCAPS was an effective way to integrate existing systems using ESBs to standardize data– and critical for healthcare providers, it offered support for HL7 data standards. JCAPS also introduced business services which allowed IT architects to design service-oriented architectures (SOA) to try to make those separate systems more responsive.
However, Oracle is quietly deprecating JCAPS — the end of extended support is next January — and customers are being advised to migrate to a different Oracle suite. With a deadline looming in less than a year, IT leaders in the healthcare industry have to start looking for a new integration solution. Now is the time to start defining the requirements for the next generation of healthcare data interoperability solution.
DevOps methodologies are core to a (modern) IT environment because they focus on strategic business demands: resilient design, rapid scale, and reliable service delivery. That last characteristic is the critical for effective DevOps environments.
The goal is for you to move through the total dev stack, as fast as your development team can code. Our new video shows how a Java app goes from being developed on an OpenShift container to launching on a production cloud instance in under five minutes.
The convergence of Mobile, Social, Big Data, and Cloud has placed increasing demands on today’s applications to react instantaneously to changes in data at a large scale. A delay of a few seconds can mean the difference between engaging or losing a customer for a retailer, increased liquidity or fraud risk for a financial institution, or escalation of an adverse occurrence in a manufacturing process or IoT network.
Many people take integration messaging for granted, and many organizations assume that any messaging platform is as fully featured as any other. But in today’s increasingly connected world, with the emergence of major trends in consumer and enterprise technology like mobile, cloud computing, big data, and the Internet of Things, your organization needs to carefully review its messaging platforms and capabilities if you hope to continue to reliably serve your customers and deliver and maintain critical advantages over your competition.
To illustrate how vital and varied messaging platforms can be, let’s explore what exactly messaging is and compare several different approaches to meeting your organization’s messaging needs.