As the Director of Product at the web-based DevOps lifecycle tool, Gitlab, Eric Brinkman takes his job at the company very seriously. Of course, he wouldn’t be in the position he is if he didn’t. His role involves releasing new features and functionalities to help solve product issues through defining requirements. But ultimately, DevOps is at the heart of Brinkman’s work and he is in charge of the first three stages of GitLab’s self-defined 10 stage DevOps lifecycle. These first stages being manage, plan and create. Brinkman tells us more about his work with DevOps, cloud and everything in between.

What exactly is meant by product strategy and roadmap?

I work on GitLab’s product strategy, and our roadmap is essentially the defined on different time scales, if you will. So, we think of strategy in kind of three to four-year chunks, we think of roadmap in three to six-month chunks. We describe our roadmap as near sighted.

What it means is that you can see things that are very close to you, but you have problems seeing things farther away. What we mean by that is basically within three months, we can tell you exactly what’s going to be released, what we’re scheduling for our dev teams to do and what features are going to come out. Beyond three, six, nine months, it becomes a little more fuzzy, we have a general idea of what we’re going to do. But we’re not exactly certain. Big things could shift plans could change.

Why is important to plan for cloud first initiatives?

I think, in general, over the past, probably five, six years or so we saw a big shift away from kind of traditional or monolithic and dedicated type hosting architectures. The reason that has happened is because of the three kind of heavyweights in the hyper scale public cloud space, so that’s AWS, Azure and Google Cloud Platform. And when you design for a cloud native or cloud first architecture you do, you just do things a little bit different, because the cloud is built to handle things differently. For example, if you deploy your application to a server that you could see, or that you knew is just a single server, and that server goes down. And that’s the only server that you have for your application, you are going to design your application differently than if you are just deploying it into a service in the cloud that is just going to handle all the details for you.

But really, the big benefit of cloud native is that it gives you a whole bunch of redundancy, it allows you to scale that application. The cloud is designed with kind of fault tolerance in mind. And so, if you deploy your application to cloud, then you don’t know exactly where that thing runs. But it is it is more kind of fault resistant than something that might be a legacy application.

In terms of assimilating cloud first initiatives, what is the biggest most like the most preventative problem that people face?

You need a place to version control your code, and you likely need a place to test that code. Inside of GitLab we call those stages create and verify. And then what happens is, as people become maybe ready to deploy their app, or get that into the hands of users, then they need to expand to deploy it, and secure it and release it, configure it, monitor it, and even do runtime security, monitoring of their application. And they realised that they can get all of this inside of a single platform as compared to something like this, where, you know, if you’re just starting out building a new application. You’ve got to think, Okay, I need a place where I can plan my work that I need to place right conversion, control my code, I need a place where I can build and test my code, you know, I need a tool to release my code, monitor secure, and so on, and so forth. And if you start to kind of RFP, each one of those little bits, you’re going to be stuck in in a lot of conversations with different vendors that are going to be trying to in business, and then not only that, you’re going to have data models that are completely scattered throughout these different tools, you’re going to have to invest into integration to piece this tool together with that tool.

What does company like GitLab mean for the DevOps world?

I think it means that there’s likely going to be a consolidation in the space, we’ve been kind of highlighting the fact that we have a single DevOps platform that’s delivered as a as a single application for a while now. And what we’re seeing in the space is a lot of other tools are either being acquired or acquiring other tools in the space to try to expand and bolt on other capabilities here in the in the DevOps lifecycle. But one of the challenges of kind of acquiring your way to a complete solution is that you have a tonne of integration to do, and especially if the, if the companies are maybe more mature, have a tonne of companies, that’s a lot of integration to take on as a company. But you’re starting to see that consolidation in the market, meaning that a monitoring company most likely realises that maybe they should be a security company,

How do you feel about GitLab and firms that are similar to yours influencing each other?

It’s hard to be influenced by similar companies, because everything is that they do is completely closed off and very secretive. Sometimes we know about it, because maybe they’ve pre-announced something. But if you flip that, it’s very easy for them to be influenced by us, because everything we do is public. I just gave that keynote, where I walked through our product roadmap, or issue tracker, which contains, I think it’s over 30,000 issues are public, you know, to the entire world, our direction pages, where we outline the strategic issues out of that 30,000 that are going to push our, our what we call our category maturity forward, is outlined very clearly. It’s very easy to tell, like what we’re going to do. We don’t think that our strategy is really that secret. It’s really more about our execution and the experience that we’re delivering. And of course, the fact that we’re open sources is a big thing, too. It’s always something has been kind of in the DNA of the company, the company was started as an open source project.

What do you think has helped the firm to become such forward thinkers in cloud native?

I think it’s very simple. It was putting GitLab CI, together with GitLab source code management. And we integrated those two things very early on. We didn’t do it because we had a master plan or because we were more intelligent or better than any of our competitors. We simply did that because it was easier for us to manage the two applications. And so we kind of merge those two things together into a single application. And it turns out that it was a it was a smash hit.

What do you think is the best thing happening in DevOps right now?

I think one of the most interesting things happening to DevOps is that the DevOps definition is expanding. We’ve seen this happened from development operations. And taking those two roles and making this thing we call DevOps today to including security into that and calling it DevSecOps, but we’re seeing the definition of DevOps even expand beyond that, to include roles like designers and product managers, and release managers, QA, even executives and legal to some extent, are getting involved in the DevOps processes. And I think that’s really cool to see as, as organisations are truly shifting and undergo digital transformation. I think it’s neat to see all these other roles come alongside the developers thought the operations and security professionals to kind of expand the definition of DevOps

What can companies be doing to integrate more DevOps into the workplace?

I think that DevOps is as much of a culture change as it is a tool set. And it really requires implementing that at all levels of the organisation. And I would say that one of the reasons that we have been so successful, and why we hold our core values so dear, is that you see, those core values lived out from the very top of the company, even at the board level of the company. And of course, this cascades on down to the to the rest of the organisation. And I think that’s what strong leadership looks like. And so I would recommend if someone’s trying to make a turn or shift into DevOps, and kind of taking the best practices of dev ops, and regardless of tool chain, it really needs to come with a methodology and a mindset, a culture change at all levels of the organisation. And that can come from the bottom up, but I’ve often seen it work best if really the higher levels buy into it.

What do you think people can be doing to take advantage of cloud?

It’s also important to make sure you know why and how you want to utilise the cloud. Because your cloud strategy will be impacted by those things. Very tangible things that people should take into consideration would be the skill set on their team. Are they familiar with AWS? Are they familiar with Azure? Do you have kind of a legacy skill set that’s going to impact as part of your decision? I think it’s going to also be important to understand what type of services you’re looking to use. For example, if you want to go kind of like full into Kubernetes events, evaluating the different services that the hyper scale public cloud providers have is going to be important for you. But I also think it’s just important to keep things simple in general.