Rafael Benevides

Rafael Benevides (@rafabene) is Director of Developer Experience at Red Hat. With many years of experience in several fields of the IT industry, he helps developers and companies all over the world to be more effective in software development. Rafael considers himself a problem solver who has a big love for sharing. He is a member of Apache DeltaSpike PMC - a Duke’s Choice Award winner project, and a speaker in conferences like JavaOne, Devoxx, TDC, DevNexus and many others.

Areas of Expertise

Java, Containers, OpenShift, Kubernetes, DevOps, Software development

Recent Posts

Why Kubernetes is The New Application Server

Have you ever wondered why you are deploying your multi-platform applications using containers? Is it just a matter of “following the hype”? In this article, I’m going to ask some provocative questions to make my case for Why Kubernetes is the new application server.

You might have noticed that the majority of languages are interpreted and use “runtimes” to execute your source code. In theory, most Node.js, Python, and Ruby code can be easily moved from one platform (Windows, Mac, Linux) to another platform. Java applications go even further by having the compiled Java class turned into a bytecode, capable of running anywhere that has a JVM (Java Virtual Machine).

The Java ecosystem provides a standard format to distribute all Java classes that are part of the same application. You can package these classes as a JAR (Java Archive), WAR (Web Archive), and EAR (Enterprise Archive) that contains the front end, back end, and libraries embedded. So I ask you: Why do you use containers to distribute your Java application? Isn’t it already supposed to be easily portable between environments?

Continue reading “Why Kubernetes is The New Application Server”


Java inside docker: What you must know to not FAIL

Many developers are (or should be) aware that Java processes running inside Linux containers (docker, rkt, runC, lxcfs, etc) don’t behave as expected when we let the JVM ergonomics set the default values for the garbage collector, heap size, and runtime compiler. When we execute a Java application without any tuning parameter like “java -jar mypplication-fat.jar”, the JVM will adjust by itself several parameters to have the best performance in the execution environment.

This blog post takes a straightforward approach to show developers what they should know when packaging their Java applications inside Linux containers.

Continue reading “Java inside docker: What you must know to not FAIL”


Automating microservices deployment with Ansible

One of the main principles of microservices is to be independently deployable. As a consequence, Microservices development and operation tend to be much more complex than a Monolith because of their distributed nature — if your IT team has not moved out yet from its silos and has adopted DevOps practices, the operations team will not really understand why they have to deploy hundreds of independent software pieces in opposite to the “good old monolith”.

“You need a mature operations team to manage lots of services, which are being redeployed regularly”  (Microservices trade-offs by Martin Fowler).

The operations team and the software development team should work together adopting DevOps practices to avoid silos and deployment process where the software team throws the software over the wall.

Screenshot 2016-11-18 13.46.37.png

Ideally, each Microservices team is multifunctional and own the software artifact from conception to production. Given the multifunctional nature of these teams, “infrastructure as code (IaC)” and automation are now a necessity. DevOps teams share the knowledge of server provisioning, configuration management and deployment. There are several tools and approaches for IaC. As an example, I can mention Kubernetes, that allows you to define its objects as yaml or json files.


A couple months ago, I published a blog post that shows how to have your own (no-cost) microservices playground.  The focus of this material is educational. It provides instructions on how to deploy each microservice independently. However, some people would like to see all of them running running in few minutes.

To show how you can run this microservices playground environment in less than 20 minutes, I decided to record the following screencast that shows how to create an OpenShift cluster using “oc cluster up” (Check out “Four creative ways to create an OpenShift/Kubernetes dev environment“), and deploy all of them using Ansible.

Continue reading “Automating microservices deployment with Ansible”


Four creative ways to create an OpenShift/Kubernetes dev environment

Developers have a lot of choices when deciding how to start using OpenShift and Kubernetes locally — without going through a native OS installation.

We all need to have a development environment as close as possible to production (to prevent defects caused by environmental differences), but ideally we need to do this without spending a lot of time to setup and a lot of computational resources (cpu, memory and disk space). This post will present four alternatives to create a local OpenShift cluster easily.

Continue reading “Four creative ways to create an OpenShift/Kubernetes dev environment”


Microservices CI/CD Pipelines in Openshift

One of the greatest advantages of using docker containers is the fact that you can move them between environments. A promotion from Development to a Production environment, shouldn’t take more than some few seconds. This is one aspect of “Continuous Delivery”

Because Microservices Architectures are “independently replaceable and upgradeable”, they are the best scenario to show a “Deployment Pipeline”.


Red Hat Developers has produced a sample and free application called “Red Hat Helloworlds MSA” that demonstrates different aspects of microservices (You can read more about this application in the following post: Have your own Microservices playground). This application shows how you can independently deploy the microservices using different technologies (JAX-RS and WildFly Swarm, Spring-boot, Vert.XNodeJS, etc) and how you can use different invocation patterns to integrate them. It also uses Netflix OSS, integrated via Kubeflix, and ZipKin for tracing.

Continue reading “Microservices CI/CD Pipelines in Openshift”


Have your own Microservices playground

Microservices are standing at the “Peak of Inflated Expectations“. It’s immeasurable the number of developers and companies that want to bring in this new development paradigm and don’t know what challenges they will face. Of course, the challenges and the reality of an Enterprise company that has been producing software for the last 10 or 20 years is totally different from the start-up company that just released its first software some months ago.


Before adopting microservices as an architectural pattern, there are several questions that need to be addressed:

  • Which languages and technologies should I adopt?
  • Where and how do I deploy my microservices?
  • How do I perform service-discovery in this environment?
  • How do I manage my data?
  • How do I design my application to handle failure? (Yes! It will fail!) 
  • How do I address authentication, monitoring and tracing?

    Continue reading “Have your own Microservices playground”


Four different approaches to run WildFly Swarm in OpenShift

WildFly Swarm 1.0.0.Final was released this week at DevNation. It allows the developer to package his application and a JavaEE runtime in a “fat-jar” file. To execute the application, the developer will only need a Java SE Runtime installed and have access to the “fat-jar”. No other downloads or configurations are needed.

Besides being a well known (and consolidated) Java EE runtime, WildFly Swarm is also an excellent choice for Cloud-native Java apps through the “built-in support for third party apps and frameworks like Logstash and NetFlix OSS projects like Hystrix and Ribbon.

OpenShift v3 is Red Hat‘s PaaS based on Linux containers and Kubernetes. It’s an amazing cloud platform that is capable of managing containers based on pre-existing Docker images or creating images from the source-code of your application in a process called S2I (Source-to-image).

This post will show 4 different approaches to deploy a WildFly Swarm application in OpenShift v3.

Continue reading “Four different approaches to run WildFly Swarm in OpenShift”


How to run Java fat-jars in Docker, Kubernetes and Openshift

In a world where agility matters, the pursuit to reduce wasted time in environment configurations is apparent in many technologies. Some techniques, such as Virtual Machines, that enable distribution of pre-configured images have existed for decades, while others like Linux containers are more recent.

Even platforms like Java allow developers to package all dependencies, resources and configuration files in single JAR (Java Archive) file. What started initially as way to have executable Java classes in Java SE (Standard Edition), has now gained notoriety also in the Enterprise. The promise to deliver runnable servers in a “fat-jar” that contains not only your application, but also the server runtime and its resources (libraries, datasources, transaction configuration, etc); made projects like WildFly Swarm, Spring Boot and Vert.x become very popular in “Java land”.

Although these projects allow the “packaging” of the server runtime, an elastic environment like “Cloud computing” stands in need of another “layer” of wrapping, and Linux containers are perfect for it. When you wrap your “fat-jar” in a container, you can also provide a custom execution environment for you JAR file that provides an Operational System, the Java Virtual Machine, and it can also be enriched with JMX (Java Management Extensions) that enable easy monitoring of the JVM. You can also set configuration flags that enable debugging, etc.

Continue reading “How to run Java fat-jars in Docker, Kubernetes and Openshift”