If you ask five DevOps engineers what they do, there’s a pretty good chance you’ll get five different answers. That’s because DevOps is more a collection of concepts than a set discipline, with teams varying in size and responsibilities based on the company.
The best way to know if DevOps is your passion is to understand each individual company and their approach to it. To get a better idea of the DevOps landscape in Chicago, we asked four companies how their teams were formed and what projects they’re working on.
Relativity, which up until recently was known as kCura, is the maker of an e-discovery platform of the same name. Relativity’s software is used by more than 13,000 organizations to sift through mounds of data in search of case-specific information.
Sameer Doshi, a DevOps architect at Relativity, talked about his role and what the team is currently working on.
How did you get into DevOps?
My first role on Relativity’s DevOps team was optimizing our build and packaging scripts before becoming an expert in deploying our Relativity application.
Over time, I became specialized in helping other teams build, deploy and manage their applications. It’s been awesome to see our movement develop into an entire industry with its own tools, best practices, experts and literature.
What project is your team working on?
We are working on building a pipeline to connect all of the different processes that build our e-discovery product, Relativity. This includes the infrastructure for the application in our cloud environments and the automated setup of the application for our end users.
Each of the components requires stable versions of the other two in order to CI, but ultimately all three have to combine automatically, regularly and constantly!
The challenge that we face is smartly embracing change in all three of these areas. But embracing this change has allowed us to adapt to customer needs. We’ve been working on this project for the last two years and expect it to last another year.
What’s the goal of this project?
The goal of our efforts is to enable all teams to introduce all three types of changes into our environment rapidly. Software engineering exists to push features and fixes rapidly and quickly to production.
Andrew Sieja, our CEO and founder, has been advocating for automated, continuous delivery since our SaaS product was launched last year. It’s a fantastic business strategy and a challenging engineering problem.
DialogTech provides analytics services to help businesses make sense of the phone calls they receive. These insights help marketing teams identify and optimize the strategies that drive phone calls. Tom Verbiscer, director of software architecture, said DialogTech got into DevOps out of necessity.
How did DialogTech get into DevOps?
Our product usage has grown and grown, and we struggled to scale up with our existing processes. We needed solutions that would allow us to be flexible and far more scalable.
What is the team working on?
We're working on projects to allow code to flow through our software development lifecycle and then out to our production release cycle faster. One project involves disabling remote console access to our servers entirely.
We've rolled some of this out to our production infrastructure already and will continue to push more of our systems in this direction while working closely with our developers to help them take ownership of the products that they work on.
What’s the goal of this project?
Creating servers that are built without any manual intervention and that push their log files out to other systems where they can be viewed has many advantages. But taking the next step of completely removing access forces us to think about these servers as immutable and treat them as "cattle,” not “pets.”
Legacy.com was founded in 1998 and has become the biggest destination for online obituaries and memorials. Patty Merkin, who is its director of DevOps, said her team was formed as a result of the company adopting agile practices.
How did Legacy.com get into DevOps?
As Legacy evolved and we became more agile, my team was lucky in that senior management recognized the value in adopting DevOps methodologies.
What is your team’s approach to DevOps?
Our DevOps team is primarily responsible for various automations (including standing and configuring infrastructure), continuous integration and continuous development processes, and providing proactive monitoring tools.
We tend to take an incremental approach to our projects and work closely with our IT and development teams, as well as product, to determine the scope of the projects we take on. We often collaborate with these groups to find the best path and tools to achieve our goals.
How has having a DevOps team benefited the company?
We've gotten to learn and incorporate new technologies into our processes, allowing Legacy to stand new infrastructure and deploy new products quicker and with greater efficiency.
Avant is an online lending platform that caters to those who can't secure a traditional loan. Its artificial intelligence tech is able to determine the creditworthiness of an applicant using factors banks and other lenders overlook.
Like many software engineers, head of DevOps Michael Air sort of fell into his role.
How did you get into DevOps?
I'd been leading a lot of operational engineering teams at Avant, such as platform and API, and this felt like the next logical step. It's a constant challenge and a fast-paced environment.
What project is your team working on?
Our main project is to migrate all our production applications to AWS using tools such as ECS, Docker and Terraform. We'll probably look at Kubernetes in the near future too.
We're aiming to complete the project within six months of starting. As lead, I'm ultimately responsible but I think everyone should (and does) feel a sense of ownership. The biggest challenge has been getting the tooling right and to a point of maturity where we can transition without loss of functionality in terms of deployments, monitoring and support.
What’s the goal of this project?
The overarching goal is to build our own internal Heroku. That means a platform that enables engineers to easily deploy, scale and monitor on a secure and battle-tested stack without having to scale up the DevOps team with each new application.
Our goal has evolved mostly as we've thought about this more as a product instead of a set of work items. We talk more and more about our engineers being our customers and what that means in terms of the platform and features we build. Every team member is encouraged to help shape our end product from features to the technologies we use.
Images via featured companies. Responses have been edited for clarity and length.
Got news to share? Let us know with a tip or a tweet @BuiltInChicago
