How true is Microsoft’s new found love for Linux?

I can’t help react to Microsoft’s new found love for Linux and Open Source with extreme suspicion. If you’ve been in the IT industry for a while then you’ll remember Steve Ballmer’s extreme vitriol for Linux, proclaiming “Linux is a cancer that attaches itself in an intellectual property sense to everything it touches“.

So where exactly does Microsoft stand? You can’t love it and hate it and the same time. Or maybe you can. I understand a change in leadership can bring a change of direction, but a radical 180 in opinion doesn’t exactly bring much confidence in their strategy. Is Microsoft finally acknowledging the rest of the world deploys their production systems to anything but Windows? Are they admitting defeat and looking for a slice of the Linux pie?

(Page views: 0)

Real life story – the journey from dev to prod with containers

This story on Techcrunch, ‘I want to run stateful containers too‘ rang home with me as it reads very similar to my own learning experience playing with containers so far, although at this point I haven’t had the opportunity to take a container based system into production, but he covers a lot of the same questions as I have so far. I imagine this journey and shift in thinking from monolithic systems to container based services is a common experience for everyone starting down this path.

(Page views: 1)

Wildfly Swarm JAX-RS in a Docker Container deployed to IBM Bluemix

More playing with Docker. Now, where can I deploy a container ‘for real’ to the cloud? A few options:

  • AWS has EC2 Container Service (ECS). If you haven’t used AWS before you can get a year of AWS for free. If you’ve already used up your free year, then it looks like you’ll have to pay as you go for ECS
  • Google Container Engine have a $300 free offer for 60 days
  • Digital Ocean – $5/month on lowest spec plan
  • Heroku has Docker support using a Docker image of their own runtime platform, Heroku Cedar. This is an interesting approach, but sounds more attractive if you’re already planning on deploying to Heroku as your target platform
  • OpenShift Origin v3 is Docker based, but only if you’re running OpenShift Origin yourself. OpenShift Online is still their own proprietary gears and cartridges (although still an awesome PaaS that I use for a lot of my side-projects – this blog is hosted on OpenShift).

So where does IBM’s Bluemix fit in to this picture? I have to admit, until seeing IBM’s presentations at JavaOne this year about how awesome their cloud service is, I hadn’t even taken a look at what they have to offer (I think years of devolping and deploying to Websphere v5 had left me emotionally scarred). Bluemix is Cloud Foundry based, with tons of other stuff thrown in. Including support for hosting Docker containers. And, free developer accounts (when CPU and stoarage kept below a certain level) – check out the pricing calculator. Ok, so I’m in, let’s get set up.

Deployment is via the CloudFoundry CLI with the IBM Containers plugin, instructions are here. Here’s a summary:

  • Installer Docker if not already installed
  • Install CloudFoundry CLI
  • Install IBM Containers cf plugin
  • Login to Bluemix: cf login -a
  • Login in IBM Containers: cf ic login (login with Bluemix credentials when prompted)

There’s a couple of options to interact with your containers and walking through the docs the first time it’s a little confusing as they list all three alternatives for each step – either with docker cli directly, with cf cli or with the ice cli.

From the Bluemix containers dashboard, when you click add custom container, the steps it gives you are using cf cli to login, and then use the Docker cli, so this is the approach I used (the ice cli seems to give me 503 Bd Gateway errors that I couldn’t get beyond, so I followed the cf and Docker steps).

There’s an interactive tutorial for using the ice utilities from here. If you’ve worked through some other online interactive tutorials then this will look familiar :-) (e.g. Git tutorial)

I already have my image running a JAX-RS endpoint using WildFly Swarm – let’s get it deployed to Bluemix.

I already have my image, built with:

docker build -t wildflyswarm-jaxrs

Next, we need to tag it:

docker tag wildflyswarm-jaxrs
  • the first param is the tag name from when we built the image
  • second param is the Bluemix image repository uri, followed by your account namespace (set when you register with Bluemix), and then the tagname for your image
To push the tagged image to the Bluemix repository:
docker push

At this point if you head over to your Bluemix Containers dahboard, you’ll see your image listed (along with some provided images from IBM):

 Using the cf cli with the IBM Containers plugin, ic), you can issue docker comands direct to Bluemix, so to list containers remotely:

cf ic images

Let’s start a container from the image!

cf ic run --name jaxrs-test

This should return you a container id.

So is it running? Let’s pass a Docker ps using cf ic:

cf ic ps

We’re up and running! (or at least building, it hasn’t started yet)

Now how do we access the service in the container? It seems like we need to go to the online console and request a public IP for the container. The free account gives you 2 free public IPs:

From the cli, the approach is to request a public ip:

cf ic ip request

and note the returned ip.

Now start the container and pass the ip from the previous step – I’m also binding 8080 from my container to 8080 on the host to make it accessible:

cf ic run -p --name jaxrs-test

The docs say the public ip may take a few minutes before it’s available.

I don’t know how long the containers in Bluemix normally take before they transition to running, for me it seemed to take a while in the ‘networking’ status.

After waiting a few minutes and checking the console, SUCCESS, we’ve transitioned to ‘running’:

And pointing a browser at the public ip and port, the app is up and running! JAX-RS using WildFly Swarm, in a Docker container, deployed to IBM Bluemix!


(Page views: 15)

DockerCon EU 2015: Getting Started with Docker Toolbox and Compose

I’ve been getting up to speed and playing with Docker recently. At DockerCon EU 2015, one of the sessions gave a walkthrough using Docker ToolBox and Compose. It’s surprisingly easy to deploy an app into a Container and get it up and running. If you haven’t looked at Docker yet, take a look at this article summarizing this session and you’ll be surprised how easy it is to get going.

(Page views: 31)

WildFly Swarm microservice development: JAX-RS app deployed to a Docker container

WildFly Swarm is an interesting approach to the ‘small is good’ current trend that is ignoring the traditional, overly large Java EE App Servers, and instead deploying self-contained, executable Jars without needing a whole App Server to execute.

Rather than requiring the whole Java EE stack, WildFly Swarm lets you chose only the implementations of the parts that your service needs to execute. Need JAX-RS? Then pull it in via a Maven dependency. Need JPA? Pull that in too. Any other required transitive dependencies are automatically pulled in via Maven. Pulling in JAX-RS also requires a Servlet container and APIs, but this is pulled in for you via Maven transitive dependencies. The end result is a self-contained, packaged Jar that contains everything it needs to run with a ‘java -jar’ command.

I’ve been spending some time recently looking at getting Weblogic Portal 10.3.6 running in a Docker container (check my work in progress changes on GitHub here). As EE containers go, it’s big. It’s heavy. If you want to describe anything as a monolith, then this is your perfect example. So switching gears I wanted to go to the other extreme and look at how you would build a lightweight Java based service, and WildfFly Swarm looked pretty interesting.

I attended one of the sessions at JavaOne this year giving an intro to Swarm, so it’s been on my todo list to take a look.

Getting started with Swarm is actually pretty easy, as it’s all driven by Maven dependencies and plugins. There’s an easy to follow tutorial here. The example apps showing different WildFly components packaged using Swarm are also worth a look here.

I worked through the examples putting together a JAX-RS helloworld app, and also a Dockerfile to package and deploy it to a Docker container. It was actually pretty easy, and my app ended up looking much like the provided examples.

My example JAX-RS resource is pretty simple, nothing complicated here:

If you’re looking for the different WildFly services that you can package with Swarm, browsing the mvnrepository is a good place to start to quickly grab the mvn deps, or browse the examples or source.

For the Maven war and wildfly-storm plugins:


Next, adding a dependency for the WildFly Swarm JAX-RS:


To build the self-contained executable Jar, build with ‘mvn package’ – this will build the app as normal to target, but also include a *-swarm.jar – this the self-contained Jar containing all the WildFly dependencies, and can be run standalone with ‘java -jar helloworld-swarm-0.0.1-SNAPSHOT-swarm.jar’

Building a Docker container

Given that we’ve now got a simple, single, self-contained Jar, deploying this into a Docker container is also pretty easy as we have no other dependencies to worry about (we just need a JVM).

An example Dockerfile would look like (scroll to the right):

FROM java:openjdk-8-jdk
ADD target/helloworld-swarm-0.0.1-SNAPSHOT-swarm.jar /opt/helloworld-swarm.jar
ENTRYPOINT ["java", "-jar", "/opt/helloworld-swarm.jar"]

All we’re doing here is:
1. Creating an image based on the official openjdk image from DockerHub

2. Adding our built WildFly Swarm jar containing our app into /opt in the image

3. Exposing port 8080

4. Defining the Entrypoint that executes when the container starts

To create an image based on this Dockerfile:

docker build -t helloworld .

To start a container based on this image:

docker run -d -p 8080:8080 imageid

… this creates a new container based on the new container, runs it as a daemon, with port 8080 in the container exposed to 8080 on the host. Done!

Hit the URL of our endpoint using the IP of the running Docker-Machine:

To watch the logs of the running container, do:

docker logs -f containerid

In this case you see the output as the WildFly Undertow Servlet container starts up, and initializes our JAX-RS based app:

Pretty simple! We’ve got a minimal WildFly server starting up inside a Docker container in about 10s, and our app deploying in 2s. That’s pretty good if you ask me :-)


(Page views: 63)

The value of simplicity in design

As a software developer I can tell you for sure that I am not a User Experience (UX) expert, but I can give you an opinion from experience on what looks good or what is easier to use verses something that is not.

What ‘looks good’ is obviously a highly subjective point of view, but what ‘works well’ or is easy to use is (again from my lack of experience as a UX expert) I assume easier to measure with a variety of metrics (think time spent on page, time spent looking for x on page, time between related clicks/keypresses, number of required navigation steps to get from x to y etc).

The reason for this post is that I’ve come across this quote a few times in multiple places over the past few days:

“… perfection is attained not when there is nothing more to add, but when there is nothing more to remove”

(from French author, Antoine de Saint Exupéry)

In software development at the lowest level, there’s a number of guiding principals that are related to simplicity, for example ‘do one thing and do it well’, with the intent that a method or a class that does one thing is far easier for a developer to understand and maintain. The current trend for microservices caries this concept through to how you structure, package and deploy your system, not as a monolithic single deployment unit, but as many smaller services that ‘do one thing and do it well’.

Bearing all the above in mind, I’ve always found it interesting how Apple clearly follows these design principals in OS X by simplifying the user experience from release to release. Even their hardware products clearly ‘do one thing and do it well’. The iPod was a perfect example of this – it was a music player and nothing else. On the other hand, Microsoft tend to take a different approach and seem to be on a never ending quest to continually add more features, with each release becoming more feature rich, more complex and more difficult to use. Think of any of the MS Office apps and the dizzying array of features each app has, and the amount of time you spend looking for the one feature that you know must be in there somewhere but it’s never in the ribbon bar where you think it should be. Presumably at some point Microsoft does usability testing with typical users – at what point though do they decide that the UX design is good or acceptable? Maybe I’m not a typical user, but if asked to give an example of a well designed and easy to use application, any Microsoft application would definitely not be first to come to mind. Apple don’t escape unscathed here either – some of the recent design changes in iTunes over the past few releases have boggled my mind (related options in different places, some on the far left of the app and some on the right).

I don’t think I had any particular point to make in this post, so I’ll leave with a link to one of my favorite UX books (again, not as an expert in this area). If you’re designing the UI for an application, please, Don’t Make Me Think.

(Page views: 97)

Weblogic Portal 10.3.6 from template: [Security:090820]The internal variable ServletInfoSpi is null and it should not be

On starting a new Weblogic Portal 10.3.6 domain created from a template of a previously created domain, you see this error:

Caused by: javax.servlet.ServletException: [Security:090820]The internal variable ServletInfoSpi is null and it should not be

As noted in this post here, the *.jks keystore files are omitted when creating from a template (is this a defect?). Copy them across from a new domain created via the config wizard into the root dir of your newly created domain fixes the issue:


(Page views: 38)

Video: Docker in 5 minutes

I’ve been spending some time working with Docker recently – it’s incredible technology and understandable why it’s getting so much attention for automating reproducible runtimes.

Here’s a quick 5 min overview covering an overview in 5 mins by Vincent Batts, who works at Red Hat on Docker and OpenShift:

(Page views: 43)

Docker on Windows: interactive tty session gives “cannot enable tty mode on non tty input”

Trying to run a shell into a running container (docker exec -it containerid bash) using DockerToolbox/docker-machine on Windows 7 gives this error:

"cannot enable tty mode on non tty input"

(this runs fine on Mac OS X)

This is logged as an issue here. As a workaround, prefix the docker command with winpty, so:

winpty docker exec -it containerid bash


(Page views: 262)

Docker ADD and COPY leave files owned by root by default

By trial and error I worked this out while building a container running Weblogic Portal 10.3.6 (see my Dockerfiles in the 10.3.6updates branch of my fork of oracle/docker:

Even if you do a ‘USER oracle’ followed by a COPY or ADD, the files transferred into the image are still owned by root. This was causing me issues as the WLST script could not read the files owned by root (as you’d expect).

This issue and the justification is described in issue 6119. It doesn’t seem that this will be fixed, it seems like it’s ‘working as designed’.

(Page views: 59)