Category Archives: Gestión del cambio

Potential and imaginary roadmap for 2015/16

I’ll talk about our Spanish middle-ware platform dedicated to offer web services (and sites, not just ws).

It’s an exercise of a potential roadmap for the next year.
Several RHEL servers in DEV, UAT and PROD , LAN, ExternalDevices (DMZ),…
Several Jboss App Servers , Apache Servers, F5 VIPs and support services (LDAP, MQ,…)
All the infrastructure that supports CI/CD. Subversion servers, Artifactory,…

Migrate Spanish CI/CD to X-Forge

That would be migrating our source code from our Subversion servers to our overlord SVN repository (let’s call it X-Forge, a dev portal in jira, confluence,etc…), our artifactory server to Nexus and our build and deploy scripts to bamboo, Sonar to Sonarcube,… It seems viable because the technology involved is compatible and the build (maven+eclipse headless) and deploy (ssh+perl+bash) scripts are invoked from Quickbuild ,but if it were Jenkins there wouldn’t be any difference, we ought to be able to migrate them to bamboo.

It isn’t in plans for 2015 so at least it won’t be before 2016. Although the technical part seems viable at first glance, there would be still a lot of details to be ironed with our overlords. Actually, the underlying organization of the code (as Eclipse PSF) and the inter-dependencies between repositories make phasing the project quite difficult (if not impossible). Actually migrating seamlessly our CD/CI infrastructure from Spain to Poland (while maintaining both for almost 2 years) was maybe one of major feat in that project (in complexity terms,  of the 200 servers I built in the new data center; the second was the SVN server while the first one was the configuration manager). Nobody was impacted so it went unnoticed (And nobody assessed the difficulty of doing it at the first try).

Revamp J2EE platform

The platform design is showing its age. I designed it 4 or 5 years ago and hasn’t been updated since them. It isn’t keeping the pace. Recent moves to agile procedures show a lack of flexibility that the powers to be have decided to overcome with what it’s called “multicontext”. Instead of creating several environments on demand (changing the platform) the solution is using the same environments to install multiple times the same j2ee apps changing their contexts (I’m a ‘rara avis’ I’m the only one that thinks this is a problem and should be considered heresy).

Although most or all of our apps could run in a Tomcat/jetty server I’d maintain the Jboss App Server due to it’s modularity, lightweight fingerprint, excellent support and synergies with other Red Hat products like FUSE (although we use other Service Bus as ESB, JBoss Fuse is elastic and looks great for cloud platforms) or BRMS (drools).

Solution 1: Migration of our applications to Pivotal CF/CloudFoundry.

Overall, maybe the best solution as it’s being deployed by our overlords. It’d allow the developers to have control of their environments and create sandboxes/environments on demand.
Of course there are problems to be addressed, it’s a pre-requisite that our CI/CD were already migrated to X-Forge and the applications should be revised and refactored to eliminate some tightly coupled functionality. Performance and stress tests are critical, it’s a shared platform. Maybe the solution is using it only for development in a first phase.

Solution 2: OpenShift V3

Maybe the best technical solution (IMHO and without knowing Pivotal in detail) for a J2EE platform like ours.

“OpenShift adds developer and operational centric tools on top of Kubernetes and Docker”.

It can be used for dev and prod environments and gives a lot of elasticity. Our apps will need to be dockerized but that is also a plus. The drawbacks as with Pivotal, the apps would need to be refactored and it isn’t a technology that it’s in our overlords roadmap/elements (while Pivotal CF seems to be the option of choice). Also dockerizing the apps will need some type of registry, access permission and change management procedures on its own.
Dockerizing Jboss will also involve upgrading the Jboss Domain Controller and a better workflow (a preliminary POC was tested in Docker: Attack on Wildfly).
This solution doesn’t require the migration to X-Forge.

Solution 3: Upgrading our JBoss servers

Upgrading our JBoss servers and changing the devops procedures for the jboss domain. It’s a solution 2 without openshift, kubernetes and docker, no cloud ability, elasticity,etc… just the improvements of a better workflow and a better refactoring (with ansible or salt) of devops procedures (creating environments, creating apps, deleting, cloning,…)
This solution doesn’t require the migration to X-Forge.

Solution 4: Refactoring the devops procedures.

Most of the complaints are related to the lack of flexibility for creating new apps and environments. That’s really an automation problem that can be resolved anytime (if I had it). The actual design can be scaled just adding extra capacity (and maybe licenses). I’ve already preliminary work in Ansible and Salt, Our overlords red line it’s a concern. This solution doesn’t require the migration to X-Forge.

Solution 5a: Not doing anything.

Keep multicontext and the same workflow (I don’t know why I detailed the other options… they have no chance against this one!)

Solution 5b:  Run.

Cloud Computing & Conway’s Law

a previous post: PaaS as change enabler, I mentioned Conway’s law as a difficulty to be addressed when looking for implementing a cloud solution.

organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations

Recently Gartner analyst: Thomas J. Bittman;Problems Encountered by 95% of Private Clouds researched which problems where suffering their clients with private clouds and found that 95% of them have problems with their solutions.

Amazon AWS (Private Clouds are things of the past) and other cloud providers/evangelists will parrot that “private clouds are inherently broken” but I can’t follow their logic on those reasons.

The problems encountered are related to the use of the technology not the technology itself, and most of them will occur implementing cloud, private or hybrid clouds.

If I had to extract a title it’d be “Companies don’t fully understand Cloud Computing“, they map their expertise, their knowledge and their organizational model to a cloud paradigm (hence Conway’s law) without fully committing/understanding all the consequences of a cloud model.

Anyway, those detected problems are critical. Addressing them mark the difference between a successful project or a failure for any company, and it usually involves a change of mindset which is cloud computing really about. A change of paradigm which without it, maybe there isn’t any difference to an advanced virtualization.

PaaS as change enabler

In a previous post Some dead ends to be acknowledged the next year , I set “No SSH in user space” as goal for 2015.

For a sysadmin it’s a mind-blowing motto (it’s like abandoning decades of practices) but few people would understand the change it involves; not only technologically but also conceptually. Actually, it’s not even a goal, it’s a byproduct of a change of paradigm.

cartoons_dilbert-pointyHairedBossAlas, pursuing it would be the worst way to achieve it, there’s no way to sell it (except maybe if you’re Oracle sales).
What needs to be sold is the idea. The paradise of a continuous delivery utopia, invention driven and with a low profile bureaucracy (wait, it can be done, sign me in!).

First we should sell the idea that other cultures are possible and they are great, the future, the way to go. “Engineering culture at Spotify part1 and part2” explains the new age really well, check the videos, they are fun and the ideas in them are great.

Second, this paradigm, this new way of working, involves a change of mentality. People must move on with the times.

If the people are sold (I’m already btw) then finally, I’d be able to sell a technology change that would enable the paradigm change.

A brief mind map of the technology solution involved (Maybe it’s not the only way to achieve it but at the moment it’s the funnier):


The technology follows a micro-services paradigm. That’s because this way we can get high performance, isolation (which allow us for better agile process, more parallelization and quick releases… check the videos), resilient and fault tolerance and allow meeting elastic demands. With those features I’m able to support that paradigm change.

How I got those features, well not with the traditional server (standalone/virtualized) way, an IaaS for provisioning and a PaaS for delivering are needed.

  • A (private/public) cloud concept (for provisioning and economy of scale) allows the elasticity needed.
  • The container model/engine (docker for example) provides the isolation, performance, development friendliness while allowing fault tolerance with easy&quick availability and fast fleet.
  • The PaaS must provide all the facilities needed to run those containers (which are really complex, fleetthey are ephemeral, they are a lot, and there are a lot of fleets)
  • The data treatment is another issue, for better or worse. It must be acknowledge.


So after this, then I’d have met my goal of no more ssh (at user space) because each container runs a reduced set of tasks (usually one). But the involved mental process (to get it) isn’t straightforward.

Anyway there are important points left that need to be considered.

  • The applications need to be highly decoupled to be splitted in micro-services. It isn’t an easy task, more in legacy software. The apps need to be designed and programmed to run in cloud environments.
  • The complexity is increased brutally.Shifted from the app to the ecosystem. It’s reduced or controlled in two ways:
    • With an organization where each team is responsible of all the areas of a micro-services.
    • Infrastructure as Code, so the IaaS and PaaS are another program to manage (with the same checks and agile procedures of coding).
  • Cooperation and isolation barriers. One micro-service/One island. Team play although each team has a dedicate role it’s the way to resolve it along with an intelligent use of apis.
  • And of course the difficulties of distributed computing and Conway’s Law.