Omnitracs has taken an interesting road to get to its current position as a leader in fleet management software for logistics and transportation companies. Their SaaS-based offering allows companies to track, monitor, and bring into compliance all of their trucks and shipping vehicles around the globe from one system. But just because Omnitracs users were taking advantage of cloud-based software as a service models of consumption doesn’t mean Omnitracs developers were fully utilizing the cloud and the agile methodology it enables.
That’s only been the case for the past year, in fact, since Omnitracs began adopting Red Hat OpenShift. Andrew Harrison, lead IT DevOps Engineer and lead of the Agents of Change team at Omnitracs, was tasked with building the company a road to the future of software development, and the pavement on this road was built with OpenShift.
Since 2014, Omnitracs has been growing rapidly, launching over 30 new products, and merging in the assets from a number of acquired companies. To keep up with all of this growth, the developers in the company had to transform their way of doing things, top to bottom.
Thus, a year ago, Harrison was placed in charge of affecting change throughout Omnitracs’ IT organization. That means introducing devops, automation, agile methodologies, and continuous integration and deployments. That’s a tall order for a single team to spread such changes through an entire enterprise.
And yet, a year later, Harrison said he’s successfully transitioned the company away from a “waterfall” style of development and deployment towards a devops and agile based approach, thanks to the help of the Red Hat OpenShift platform. Instead of code pouring in as it was completed, like a waterfall, developers were able to iterate over time in smaller chunks. While the move began with OpenShift 3.11, the company was also one of the first to roll OpenShift 4.1 out to production systems.
Harrison said the benefits of moving to OpenShift 3.11 were immediately noticeable. “With OpenShift 3.11, we were able to get immediate cost reduction because we moved everything out to the public cloud [eliminating on prem costs]. We got rid of on-premise costs immediately. We wrote custom Ansible playbooks to make sure everything was infrastructure as code and was always repeatable. We reduced our environment deployment times from over a week to less than 2 hours,” said Harrison.
Those technical wins were paralleled by cultural wins as well, he added. “We had a total transformation in the IT department, especially in our organization. Our team, The Agents of Change, evolved from the traditional waterfall style to a real agile methodology which greatly reduced all of our release times.”
Soon after moving onto OpenShift, the team at Omnitracs embraced OpenShift 4.1 and the Operators model for services availability.Harrison noted that the Operators model enabled faster integration of services essential to building out a production-grade cluster. The team now uses Splunk for logging, and Ansible for automation.
Software is not the only thing changing inside the Omnitracs OpenShift clusters, however. The company is also using this Kubernetes-based cloud software to improve its internal IT teams. Said Harrison: “We took the SRE [Site Reliability Engineering] model and turned it on its ear a little. We’re spinning up 35 new scrum teams in the coming years, and we’re not going to find SREs for each of those teams; it’s not going to work. So we took a different approach: we’re using a virtual ops approach, where we’re embedding with these teams now and teaching them the ops part of devops. They are going to be their own SREs. They will have the ability and proper permissions in OpenShift to spin up their own namespaces, start projects, give people access to them, and all of that. We’re really giving them the ability to provide care and feeding for their own areas, but at the same time, giving them the ownership of it. So now when they are building their applications, they are actively thinking about the operationalization of it,” said Harrison.
That transition also means internal developers are expanding their skill sets to include more capabilities, enhancing their resumes and growing their careers while also contributing to the growth of the company itself. It’s a win-win situation. “They know that the logs are collected in Splunk and through VictorOps, they get that notification back when something’s gone wrong. It’s just part of how they do their daily job now,” said Harrison.
How did they manage to put all this power into the hands of the developers themselves? “Early adoption of OpenShift 4 was critical to our success. We were very much looking at this as if we were going to be on this for the next five years and didn’t want to get stuck on an older version, so we took that risk. We were very tightly working with Red Hat while doing this. They’ve been embedded with our teams for the last year. They are a part of our team. We drove innovation within our team and within Red Hat. The stuff we were working on was being brought back into Red Hat to bring the platform to where it is today,” said Harrison.
“That transformation we talked about earlier from traditional systems administrators in an operational role to devops engineers, we did that in less than a year. We weren’t doing this a year ago. We were traditional systems administrators in our silos. We had Linux guys, we had VMware guys, we had network guys. Now we’re all on a team together, we’re all doing this stuff every day. It’s been an amazing transformation for the technology we’re working in and for our careers. It’s been great, and that tight partnership facilitated that shift very easily. Having Operators available to us allowed us to deliver services to the dev teams almost immediately on day one,” said Harrison.