Intraway is getting dockerized!!!

If you worked at Intraway you can tell the story that deployment time was measured in days, or that collaboration with a project that was unfamiliar to you was measured in weeks. That was our reality.

Lots of time was lost in workspace setup, component deployment and component integration. And that time was not planned, so the project always suffered.

Did you know that a whole week was needed to create and deploy a release candidate of our main product to a testing environment? And it was a manual process.

I don't have to explain why that was inadmissible for our business.

Our own complexity

Intraway has complex products, that handle mission-critical solutions. We have at least 3 main programming languages (PHP, Java, C++), simulators, third party software, external devices, databases and more on our products. All of which are deployed over several architectures and versions of operative systems.

Every part of the system has an owner and its own roadmap. Nobody knows in detail how every component works, and we should keep it that way.

Our complexity is laid on integration and shipping.

Docker to the rescue

About a year ago we started a lot of initiatives related to the standardization of building, shipping and releasing, aimed at improving our time to market and software quality.

One of them was dockerization.

After a lot of effort on the part of the Technology and Delivery teams, our status is:

• All of our base environments (building, releasing, testing) are in docker
• Our Continuous Integration System is fully dockerized
• More than 70% of our components generate a docker container from our CI when a commit is done
• New testing environments are created with docker
• Almost all developers and professional services teams work with docker on a daily basis

Now, the release and deploy of a release candidate for our star product into a testing environment now takes less than an hour and is fully automated. That is 0,59% of the time that the same process took one year ago.

Now we needn't care about how a component is installed and configured if we want to use it, we just use the docker container. We don't have to lose time setting up a workspace environment, we just use the development docker that already has all the necessary tools.

We no longer need lots of machines or vms installed with different versions of RH6_32t, RH6_64, RH5_32, RH7_64, etc. We just use the correct docker container to test our code.

Are you taking notes….

Our next challenge

Our first priority is to continue migrating all products and components to our building and releasing with docker.

Simultaneously we are working to finish our Continuous Integration System to support releasing of dockers. We will no longer ship rpms, we will also ship a stable and tested docker.

Yes, I know. What about docker in production environments?

The answer is that we are going that way.

Let me list the main concerns that we must address first:

• Performance: We need to ensure that performance is not affected using docker.
• Componentization: Some components must be split in order to reduce container sizing and isolate behavior.
• Docker tuning: Fine tuning must be done to docker images before putting them into production.
• Server upgrades: Our clients must upgrade to RH7 in order to support docker.

We are gonna make it happen. Just think about where we were one year ago.

@technology