The rise of microservices architectures drastically changed the software development landscape. In the past few years, we have seen a shift from centralized monoliths to distributed computing that benefits from cloud infrastructure. With distributed deployments, the adoption of microservices, and system scaling to cloud levels, new problems emerged, as well as new components that tried to solve the problems.
By now, you most likely have heard that the service mesh or Istio is here to save the day. However, you might be wondering how it fits with your current enterprise integration investments and API management initiatives. That is what I discuss in this article.
Continue reading “Distributed microservices architecture: Enterprise integration, Istio, and managed API gateways”
What Red Hat is providing
Red Hat OpenShift Application Runtimes (RHOAR) is a recommended set of products, tools, and components for developing and maintaining cloud-native applications on the Red Hat OpenShift platform. As part of this offering, Red Hat is extending its support to Spring Boot 2 and related frameworks for building modern, production-grade, Java-based cloud-native applications.
Spring Boot lets you create opinionated Spring-based standalone applications. The Spring Boot runtime also integrates with the OpenShift platform, allowing your services to externalize their configuration, implement health checks, provide resiliency and failover, and much more. To learn more about how Spring Boot applications integrate with the wider Red Hat portfolio, check out the following OpenShift Commons Briefing by Thomas Qvarnstrom:
Continue reading “Extending support to Spring Boot 2.x for Red Hat OpenShift Application Runtimes”
In this article, I’ll give you a quick tour of how to use the new MicroProfile Starter (Beta) site to generate, download, and build a Maven-based MicroProfile project with just a few clicks. Using this online project generator, you choose the MicroProfile version and server (such as Thorntail) that you want your project to be based on. Then you’ll be able to choose what example code to include in your project to see how to use the APIs that are part of the MicroProfile specifications such as Config, Health Check, Metrics, CDI, and more.
Continue reading “Jumpstart your microservices development with MicroProfile Starter (Beta)”
This article is the second in a series of three articles about Red Hat Integration. The first article described how the new Red Hat Integration bundle allows citizen integrators to quickly provide an API through tools that make creating an API in five simple steps effortless, and we implemented a demo showing the full API lifecycle on Red Hat Integration. The demo was about providing wine labeling and ranking info via APIs.
In this article, I am going to take you further by implementing a real business transaction with Salesforce. We will create an event-driven integration solution with no code on Red Hat Integration.
The idea of this demo is to receive an order from the client web application through a gated, secured API that will then process the order and forward the needed data to the corresponding Salesforce modules. From there, Salesforce will take care of the order content.
Continue reading “Full integration to Salesforce with Red Hat Integration (Part 2)”
Microservices architecture is taking over software development discussions everywhere. More and more companies are adapting to develop microservices as the core of their new systems. However, when going beyond the “microservices 101” googled tutorial, required services communications become more and more complex. Scalable, distributed systems, container-native microservices, and serverless functions benefit from decoupled communications to access other dependent services. Asynchronous (non-blocking) direct or brokered interaction is usually referred to as messaging.
Continue reading “Announcing Kubernetes-native self-service messaging with Red Hat AMQ Online”
This is the finale of a series on whether Kubernetes is the new Application Server. In this part I discuss the choice between Kubernetes, a traditional application server, and alternatives. Such alternatives can be referred to as “Just enough Application Server”, like Thorntail. There are several articles on Thorntail (previously known as Wildfly Swarm) on the Red Hat Developer blog. A good introduction to Thorntail is in the 2.2 product announcement.
Continue reading Curse you choices! Kubernetes or Application Servers? (Part 3)
Developing Apache Camel and Red Hat Fuse applications inside VS Code is improving! In my previous articles, I’ve mentioned that Camel URI completion is available in VS Code for XML and Java DSL. By leveraging several VS Code extensions, it is now possible to have an end-to-end development experience. The Camel tooling currently available in VS Code is primarily targeting Spring Boot– based Camel applications. The tooling covers the development process from creating a Camel project, testing, and debugging it locally, to automatically-rebuilding and redeploying it on your local OpenShift/Kubernetes instance when you make changes.
There are several ways to leverage the VS Code tooling. I will show the process which I believe is the easiest one to get started with.
Continue reading “Using VS Code to develop Spring Boot-based Camel and Red Hat Fuse projects”
In Part 5 this series, we looked into details that determine how your integration becomes the key to transforming your customer experience.
It started with laying out the process of how I’ve approached the use case by researching successful customer portfolio solutions as the basis for a generic architectural blueprint. Now it’s time to cover various blueprint details.
This article covers the final elements in the blueprint, storage services, which are fundamental to the generic architectural overview.
Continue reading “Integration of storage services (part 6)”
Nowadays technology companies are adopting the API as one of the most valuable pieces of their business.
What does it mean when we talk about API-first development? We already know the benefits of using an API-first approach:
- Reduced interdependencies
- Earlier validation
- Early feedback with the freedom to change
- Improved efficiency
This article describes what it means to use the API-first design approach. It also walks through an example of using this approach with the OpenAPI Specification and with oas-tools as the Node.js back-end application, which enables you to care only about the business logic. All the validation of incoming requests are done by the
oas-tools library (based on the OpenAPI Specification file provided).
Continue reading “Building a Node.js service using the API-first approach”
In Part 4 of this series, we looked into details that determine how your integration becomes the key to transforming your omnichannel customer experience.
It started with laying out the process of how I’ve approached the use case by researching successful customer portfolio solutions as the basis for a generic architectural blueprint. Now it’s time to cover more blueprint details.
This article discusses the core elements in the blueprint (container platform and microservices) that are crucial to the generic architectural overview.
Continue reading “Integration of container platform essentials (Part 5)”