For this Q&A on DevOps implementations, we caught up with Aater Suleman, co-founder and CEO of Flux7, an Austin-based IT consultancy that is focused on cloud technology, DevOps, and advanced development. Suleman began his career in hardware architecture and performance optimization, but has spent nearly a decade now working with cloud technologies and is a frequent speaker at DevOps and Cloud development events. Suleman also serves as a member of the faculty of the University of Texas, Austin.
We wanted to ask Suleman a number of questions regarding what he’s learned from the DevOps implementations he’s been a part of since founding Flux7. He’s that interview.
DevOps: When you see teams moving to DevOps, what do you think they need to do in order to move forward with good workflow?
Suleman: A very strong focus on automation and continuous improvement is required. And to succeed there, you need to monitor developer workflows very cautiously.
Simply looking at architectural diagrams and making plans is not enough. You don’t learn much about an organization from diagrams. You want to look at the IT infrastructure, sure – but you need to break into conversations with developers and IT team members about what they are actually doing day to day. You will learn much more from those interviews. When we interview developers and IT team members, it’s astonishing how much emerges out of these discussions. Companies learn that they really don’t know as much as they thought they did about their employee’s day-to-day activities and workflow.
DevOps: What are some of the common lessons learned?
Suleman: One of our clients recently requested that we help them set up Continuous Integration and Continuous Delivery (CI/CD). I insisted that make sure that was what they actually needed. We held conversations with business executives to try to understand their business requirements, and then moved along the rest of the enterprise and IT stack.
And through that process, it became very clear that while CI/CD would be great, they did not have anyone with the skills to craft automated tests. So even if we put in place a framework for automated testing, there’s no QA person who could write those tests.
Another thing that became very obvious was that their developers were experiencing a lot of pain in their development environments. They were trying to perform basic testing, but they did not have an efficient way of testing from their laptops.
The developers were, for instance, logging into a remote server for testing, but the Internet connection to the server was slow enough that the connection would break. It was common for them to press a key and not see a result for a long period of time.
It was a very frustrating environment for them to be able to get any kind of development done. That’s when the priority actually became to build a robust developer environment for this firm.
Fortunately, and this is where interviewing team members really benefits, we discovered that one of the developers had actually created a local developer environment. He hadn’t told anybody, and was using it on his own laptop, but had never standardized it for use across the enterprise.
The interesting story here is that they, despite wanting to move to CI/CD, they were not yet ready. Rven more interesting, they already had a solution to their biggest problem in the company that just nobody knew about.
DevOps: What do you see as some of the ways enterprises often fail?
Suleman: DevOps implementations tend to be very buzzword-driven. People have heard of CI/CD, and they want to implement integration testing right away, because everyone’s saying that it’s a good thing.
But you have to look at your specific needs and where your top issues are right now from a business requirement and delivery standpoint. CI/CD is an excellent thing, and I think it needs to be there for every single team. But what’s also important is to see exactly where your current challenges are and address those first.
Also, typically, if it’s a mid-size startup that is just beginning to hit the rapid “hockey stick” phase of growth, those tend to make for very interesting assessments. That’s when there’s enough flexibility in the company to make quick changes with very big impact. And that’s why it is also a very important time for companies to do something like this is.
One aspect of assessments at this stage of the business is whether this infrastructure team really understands the need for the enterprise to have the ability to scale. I’ve seen infrastructure teams make mistakes on both ends of the equation here. At times, the IT teams are overestimating, overvaluing the scaling they need. And they learn from the business team that, while they are scaling, there’s a more important challenge somewhere else.
The other extreme, at times, is the business teams are foreseeing a huge hockey-stick style increase in demand, but IT is more focused on putting out more features, and deploying more, instead of scaling the infrastructure. We see these kinds of disconnects all of the time.
DevOps: What are some easy wins enterprises can achieve when it comes to being able to innovate more quickly?
Suleman: Maintaining uptime and reliability in a DevOps environment also means that your QA team has more responsibility to production-ready and developers also now need to be move out code that’s relatively clean and correct.
Another aspect is that developers still need an IT playground so that they can innovate. You want to provide them with environments that are local to them, so they’re not afraid to try to build creative stuff. And these environments need to be fast, and they need to be production-like. And they should be completely isolated and easy to recreate so that developers can innovate fast. And if they break something, the cost of a mistake is very low, because that’s the only way you innovate, is by lowering the cost of failure.
That’s exactly how we did it, actually. So killing and spinning up a new dev environment was done in one minute and twenty seconds. And developers leveraged that capability quite a bit. Many developers are now actually rebuilding the environment multiple times a day. Previous to having an automated development test environment, the developers didn’t innovate as much because they didn’t have the ability to fail fast and cheaply.