In Part 1, I implemented a simple database application using Wildfly Swarm and deployed it on Openshift. In this article, I am going to do the same but using Spring Boot instead so that you can see the difference between using different frameworks for your development. I shall also describe the use of spring-cloud-starter-kubernetes-config in accessing ConfigMap in Openshift deployment which is slightly different from I I read in the documentation.
At the end of this article, I shall summarise my view on the pros and cons of each framework in the context of ease of developing this simple database application. You may want to compare it with the Verti.x and Fuse Integration Services (FIS) implementation in my previous 2-part article on Vert.x (Part 1 and Part2). By the way, the FIS implementation is also using Spring Boot but it uses FUSE’s REST Domain Specific Language (DSL). Continue reading RHOAR: Wildfly Swarm vs Spring Boot Microservices – Part 2
Red Hat Openshift Application Runtime (RHOAR) comes with a number of frameworks/toolkits for implementing microservices. In previous articles on Vert.x (Part1 and Part2), I compared Vert.x with Fuse Integration Services (FIS). I am going to compare two other popular frameworks that come with RHOAR in this article. They are: Wildfly Swarm and Spring Boot. I am going to show you how to implement the same database access application implemented in Vert.x and FIS in my two previous articles so that you can compare the level of difficulty for using these frameworks. This is kind of an unfair comparison as most of you are either JEE or Spring developers and you will always find that your framework is easier to use than others especially when compared to Vert.x as it requires learning a new way (reactive programming) of implementing an application. Continue reading RHOAR: Wildfly Swarm vs Spring Boot Microservices – Part 1
In Part 1, I described the FIS-based microservice using a relational database and replicated its functionality using Vert.x, MongoDB with Guice dependency injection. The RestVerticle, which implements the RESTful microservice calls the CustomerService which retrieves/saves customer info to the MongoDB directly. In this article, I am going to show you how you can convert the CustomerService to run as a separate verticle called CustomerVerticle and have the RestVerticle communicate with the CustomerVerticle via the Vert.x EventBus. For a simple application such as this, there is no advantage to code the application this way. I am doing this to show you how this can be done as more complex Vert.x applications usually have multiple verticles running and communicating over the EventBus. To enable verticles to communicate over the EventBus, there is usually some boiler code needed to send messages and listen to messages over the EventBus. I am going to show you how to create a service proxy using code generation to obviate the need to write the boiler plate code yourself and convert the application developed in Part 1 to use the service proxy using dependency injection. Continue reading RHOAR: Vert.x Microservices Toolkit Compared to Fuse Integration Services – Part 2
Red Hat recently released the Red Hat Openshift Application Runtimes (RHOAR) which includes a number of useful frameworks/toolkits including: Wildfly Swarm, Vert.x, Spring Boot, Netflix OSS and node.js (technology preview).
Among the RHOAR components, Vert.x is completely new to me. Vert.x is a polyglot toolkit for building reactive applications on the JVM. This means that, like node.js, it is event driven and non-blocking and can handle high concurrency using a small number of kernel threads. In other words, it can scale with minimal hardware. In this article, I am going to experiment with Vert.x and compare it to Fuse Integration Servcies (FIS) in building a cloud native microservice. So, please join me on my journey into the world of Vert.x and build a Vert.x application which uses dependency injection deployed on Openshift. Continue reading RHOAR: Vert.x Microservices Toolkit Compared to Fuse Integration Services – Part 1
In my previous article, I created a reusable FIS demo. Today, I am going to show you how to use the 3scale API Management Platform to create an API for the FIS ‘products’ service. By doing so, the service gains non-functional capabilities including access control, rate limits, analytics, activeDocs, billing & payment, etc. Starting my learning journey with 3scale, I decided to set up my own self-managed 3scale gateway and use an online swagger editor to create a swagger spec to document the service. During my journey, I ran into some gotchas, mysterious behaviours, and problems that were eventually overcome. Overall, it was a good learning experience although frustrating at times. I am sharing my learning journey with you pictorially in this article. Hope you’ll find it useful. Continue reading Exposing FIS-based Service as a 3scale API – My Learning Journey Part 1
Recently a potential customer wants to see how FIS 2.0-based services and API Management can work together to replace the integration platform he is currently using. The customer has asked another vendor to do a PoC on AWS. Red Hat has been invited to do the same but called it a demo. Consequently, we set up Openshift on Google Cloud Platform for the demo. In this article, I am going to describe only the FIS implementation of the use case mandated by the customer. The FIS 2.0 and 3Scale integration is covered in another article. Continue reading A Reusable Fuse Integration Services 2.0 Demo
Fuse Integration Services 2.0 (FIS 2.0) for Openshift introduces a number of new features. In my opinion, the most exciting ones are the introduction of S2I binary workflow and Spring Boot support. We shall be using these 2 new features in this article. As FIS is for Openshift, as its name implies, one needs a development Openshift environment to experiment with it. There are several ways to set up a development Openshift environment on your laptop. The following are the most popular options:
- oc cluster up – this is a relatively new feature introduced in Openshift Origin 1.3. This option uses a containerized version of Openshift and runs it locally on your laptop. It requires Docker to run.
- Red Hat Development Suite (RHDS) – this development suite comes with an installer (Windows and Mac only at present) that installs JBoss Developer Studio, Red Hat Container Development Kit and all the necessary dependencies. It is based on Vagrant, VirtualBox. Openshift Enterprise and Red Hat Enterprise Linux. In contrast to option 1 which is based on Docker, RHDS is based on a virtual machine or VM.
Continue reading Experiment with FIS 2.0 with the Absolute Minimum Setup