Hey, developers! Do you care about using the best practices to apply your application to the cloud? If so then you should be using The 12-factor App, which is a methodology for building software-as-a-service. Today I like to talk about the 12-factor App, which I had presented to a group at the Red Hat Summit last month.
Continue reading “12 Factors to Cloud Success”
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”
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.
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”
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”
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.X, NodeJS, 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”
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:
Continue reading “Have your own Microservices playground”
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”
“Linux containers (sometimes managed using the docker command) keep applications and their runtime components together by combining lightweight application isolation with an image-based deployment method”. ( http://developers.redhat.com/containers/ )
Continue reading Dockerfile, `docker` CLI, containers “Cheat Sheet” now available!
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”
A recent blog post, 10 things to avoid in docker containers, describes ten scenarios you should avoid when dealing with docker containers. However, recommendation #3 – Don’t create large images and the sentence “Don’t install unnecessary packages or run “updates” (yum update) that download files to a new image layer” has generated quite a few questions. Some of you are wondering how a simple “yum update” can create a large image. In an attempt to clarify the point, this post explains how docker images work, some solutions to maintain a small docker image, yet still keep it up to date.
Continue reading “Keep it small: a closer look at Docker image sizing”
