Interview: DevOps Pipelines with Tuomas Keränen, Eficode

Lauri (00:09):

Hello, and welcome to DevOps Sauna. My name is Lauri and I am the Chief Marketing Officer of Eficode. Almost every time we talk about DevOps, we come across the question about culture versus tools. Some people say there is no such thing as DevOps tools. Some say that if you're adopting tools without culture then you're doing DevOps in the wrong way. Nicole Forsgren, Jez Humble and Gene Kim say, in their Accelerate book, the following words. "What tools or technology you use is irrelevant if the people who must use them hate using them, or if they don't achieve the outcomes and enable the behaviors we care about."

Lauri (00:53):

I had a chance to spend a moment with Tuomas Keränen, product manager for Eficode ROOT DevOps platform, and I asked him to lay the stepping stones for anyone who is evaluating their tools used to embrace DevOps in their organization.

Lauri (01:15):

Welcome, Tuomas. How are you liking the winter time? Mornings are bright.

Tuomas (01:21):

That's true. And the evenings are dark.

Lauri (01:26):

Yeah. Two days ago I finished my day 5:20 and I decided to go on a run because I was hoping that it would still be daylight. It was pitch black.

Tuomas (01:36):

Yeah.

Lauri (01:38):

I was thinking that maybe I should start exercising in the morning and start my working day at 9:30 or 10 o'clock, because it doesn't matter whether it has been pitch black for one hour or three hours after I finished my working day.

Tuomas (01:52):

That's true. That's what I do actually. I do my jogging early in the morning, right after I wake up.

Lauri (02:00):

Oh, interesting.

Tuomas (02:01):

Yes.

Lauri (02:01):

Yeah. Somehow I have never got into that. I can do that, but I never got into that habit. Today, we are not talking about the winter time we are talking about the DevOps pipeline.

Tuomas (02:12):

Yes.

Lauri (02:13):

A lot of conversations we're going to have today talks about whether you should go for one vendor or multiple vendors. As it happens, we asked that question from our contacts in our marketing platforms. So when people join our webinars, when they read a guide, we ask them, "What is your preferred solution vendor?", or, "Which solution vendor would you like most support with?" And interestingly enough, we can see that approximately 50% of respondents say that they prefer multiple vendors. And then the remaining 50% of the respondents pick then Azure or Atlassian or Jenkins, or some other platform provider. But all of those solution vendors somehow relate to the DevOps pipeline, which is a term that a lot of people use, but maybe it hasn't been really, really defined. So why don't we start by just giving you the floor? Introduce yourself, who you are and what's your role, and then what is this DevOps pipeline in your definition?

Tuomas (03:25):

Yeah. Okay. Sure. So my name is Tuomas Keränen and I work as a product manager at Eficode. I am responsible for Eficode DevOps tooling service, Eficode ROOT, so that's my job. And well, what is a DevOps pipeline? Typically, the DevOps tooling pipeline, it covers all the tools that the software project managers, developers, quality assurance and operations engineers use in their daily work. In essence, it is the tooling pipeline, or maybe you could use the word assembly line as well, that they use for turning requirements to code running in production.

Tuomas (04:18):

From the functional perspective, it contains tools for project management, document management, there are typically integrations within communications tools such as Slack or Microsoft Teams, there's a tool for source control or version control. Then it also includes the complete CICD pipeline, meaning the build tools, tools for study code analysis, a place where to store the binaries, a tool for scanning through all the open source components that you include to be part of your software, and then various tools for automated testing and deployments. For the operations side, it also includes, typically, the tools that you're using for monitoring the environments.

Tuomas (05:16):

Then you have a tool for controlling access to the system, so user management integration at least, and then you'll need also some analytics so that you'll get full visibility to the pipeline, and to the way that the teams are actually using the tool chain. So that is what I mean by a DevOps pipeline.

Lauri (05:41):

That is a very comprehensive set of documents. I think I have read papers from Gartner, I think Gartner's, at some point, they used the term application release orchestration. I think now they use the term value stream delivery platform, or value stream management platform that is here. But then there are some companies, I imagine, who provide all of that, but then probably more often than not, everything that you just described is a combination coming from multiple vendors. So you could argue that there is a way to go and get a suite that does all of that, or at least the big parts of that, and then there is another way of, say, getting a DevOps platform and then bring the best solutions and individual parts from multiple vendors in this. Open us a little bit about this DevOps platform, best of breed versus integrated suite approach.

Tuomas (06:45):

So by a multi-vendor or a best of breed pipeline, I mean a solution where you hand pick the tools for each of the tasks that I listed. For example, you take the project management system from one vendor, then the version control functionality comes from another one, and then you use a third solution for the CICD part, and integrate the tools coming from multiple vendors together, or you let somebody else to do the integration work for you.

Tuomas (07:27):

By a single-vendor pipeline, I mean a solution where you aim to take as many tools as possible from the same tool provider. So you take the project management tool, the version control tool, as well as the CICD part, from the same tooling brand. It could be Atlassian, it could be GitLab GitHub or something alike.

Tuomas (07:56):

Then the integrated tool chains or single-vendor tool chains, they can be further divided into categories. You have solutions that come with certain public cloud infrastructure as a service solution, such as Microsoft Azure, or AWS. Then you have solutions that are basically code service provider independent, these are the examples that I already gave Atlassian, GitLab GitHub and alike. There are certain pros and cons that come with these approaches that you have to take into account when you're making the selection.

Lauri (08:43):

Can you put a line between when it's a good idea to go for a suite and when it's a good idea to go for a DevOps platform?

Tuomas (08:49):

Of course, the suitability of these solutions depends highly on the type of software that you're creating, the tools that you have used in the past and so forth. There are a few pipeline user types that benefit from a single-vendor tool chain specifically. First of all, start ups. If you start from a clean slate, the options that you have available are different, compared to a situation when you have existing investments to a certain tool or tool chain, and moving away from the existing set up that you have in place might be actually quite costly in that case. Also, if you need a quick start, and you do not want to spend any time in more detailed tool selection, then a fully integrated option could be handy.

Tuomas (09:55):

Also, if you aim to keep things very simple, and you are ready to make certain trade-offs, in terms of certain components that belong to the integrated pipelines, then those might be a good option. Also, if you've made a decision to use one of the cloud services to run all or most of the applications and solutions that you are creating, then taking the tool chain directly from the cloud service vendor might make sense. Of course, you have to be careful that you do not paint yourself in a corner with these decisions, and you have to be careful that you do not make any decisions that you would have to later regret.

Tuomas (10:45):

One of the key factors here may be cost as well. Sometimes it is more cost effective to buy all the features from a single vendor, instead of buying the same functionality from multiple tool providers.

Lauri (11:06):

Yeah. I remember there's an expression coming from Amazon management style, they use a term, "One way door" and "Two way door", which means that you can make decisions that are hard to back out, so they are doors that you can only go one way, and then there are doors that go both ways. We will come back to that towards the end but it's a good reminder that you don't paint yourself in the corner, because painting yourself in a corner is clearly a bad example of a one way door. But more often than not, if you are an existing organization, existing software development team, you probably already have some existing code. You maybe even have, let's say, fragments of DevOps pipeline in your organization, maybe not structured as well as you would like them to be structured. Do I interpret correctly that, in that case, you would be inclined to look into the DevOps platform option?

Tuomas (12:05):

I am not saying that an integrated single-vendor solution is completely out of question in these cases. However, I am saying that the multi-vendor, best of breed solution may be more practical in many ways. If the teams already use and like a specific tool, you do not have to throw it away, but you can keep using it when you choose to take the best of breed option. And if you have certain tools that you are not happy with, you can always replace them with a better alternative if necessary. Also, one benefit of running a best of breed tool chain is that you can almost always replace any part of the tool chain with a competing solution if you think that it actually makes sense, at any point in time. Although the integrated pipelines are getting better all the time, there will always be some weak links in them compared to the solutions provided by more specialized tool vendors.

Lauri (13:18):

I can also imagine that in those cases where you can swap in and swap out different products, it would also provide, let's say, better developer experience. What I mean by that is, I remember, at least from some of the Dora research and Accelerate book, when developers get to participate in the tool selection, it tends to bring a happier workplace. The risk I can see, and maybe I'm just making it up myself, but this type of DevOps platform is a jigsaw puzzle. You have to go and find the right parts and you have to make sure that the different parts of jigsaw fit together, and that the outcome is the picture you want.

Tuomas (14:06):

It can be a jigsaw puzzle, yes. So you have to integrate the solution so that the information flows smoothly from a tool to another. Typically, this means that you'll need a bunch of plugins and extensions that glue the parts of the system, so that they would actually function as a seamless assembly line, rather than just a random selection of tools coming from multiple vendors. Once you've done that, then you have to make sure that the integrations actually stay intact so that they won't break. If they break, you'll have to fix them. Additionally, you will need expertise related to a multitude of tools, how to keep them running, how to keep them up to date and so forth. So there is certain amount of work that comes together with the best of breed approach.

Tuomas (15:04):

The good news is that you do not necessarily have to do this by yourself. There are partners who are able to help you with tool chain maintenance and support. There are also solutions available that solve some of the common issues related to the multi-vendor tooling pipelines. For example, there are centralized access control tools that enable you to control access to the tool chains centrally, rather than managing access tool by tool. There are analytics solutions in place that provide visibility across the multi-vendor tool chain, like I said in the beginning, so that you don't have to go through all the tools individually to get an overview to a project, but the most essential data is gathered in a centralized dashboard view or views. With single tool vendors, or single-vendor tool suites, these functionalities may be part of the overall service from the beginning, obviously.

Lauri (16:16):

Do you often see a situation that organizations have a DevOps platform, and then they have multiple vendors in the platform for one part of the pipeline, but it is used by different teams, yet they still use the same platform?

Tuomas (16:33):

Yeah. There are certain tools that we think that you should always centralize so that everybody is using more or less same set of tools in certain areas, no matter what sort of software they're building, what technologies they are using and so forth. For example, project management, document management, version control, binary management, those are functions that everybody should be sharing, just to make sure that all the critical assets like requirements, documentation, source code, binaries, they are always stored safely, and you have the backups available, and the information that is stored in these systems, it stays shareable between the projects across the organization.

Tuomas (17:16):

But then certain technology, or project specific requirements, in certain other areas like on the CICD side, and it may make sense to have some flexibility there so that if you are developing for a specific cloud platform, it might make sense to use the cloud platform native CICD pipelines, rather than something that is more generic. You might still have, of course, cloud platform independent system as an alternative, based on some other technologies, but if you're building for a, let's say, software that will eventually run on AWS, it might make sense to take advantage of the AWS code pipeline as a tool chain for the CICD part, so that the teams are actually able to choose the solutions that fit them the best.

Lauri (18:11):

Yeah. I'm thinking, how would a software development organization decide between which way to go? Maybe that's the big question, and then you go for the detail level questions after that. But let's take a concrete example. So company, like manufacturing company, that is undergoing that digital transformation, and they're providing maybe machinery for industrial buildings or mining or some other things, and they have hardware, in the real life, they can have hardware with embedded software, so that's what their primary product is that they sell. They maybe have software that runs on your Windows or Mac computer by the professional users, like field service engineers or some other type of professional people. Then you would have mobile software for customers, as end-users.

Lauri (19:11):

I'm trying to paint a realistic picture of a large enterprise where software is very much everywhere. It's in the machine that you ship to the customer, it's probably somewhere in the cloud, you have a native client running on a PC because maybe you need graphics acceleration, I don't know, and then you have easy mobile software for end-users. What factors, in that case, would you consider when you start thinking about the possible applications for the DevOps pipeline?

Tuomas (19:39):

I'm going to assume here that some tools, or tool chains, are already in use, so we are not able to start from a clean slate. First thing to do is to see if there is a common platform in use, or if the teams developing desktop server and mobile software in this case are still using unit or even team specific tool chains. That gives you an idea of the starting point. Then you'll have to identify the tool chain components that should be shared across all the teams, no matter what type of software they are creating. Like I said, project management, document management and version control systems are likely candidates here. Then the question is that, should the CICD pipelines be consolidated as well, along with the rest of the centralized tools, or should the teams have some flexibility there?

Tuomas (20:43):

If yes, meaning that the CICD pipelines should be consolidated along with the rest of the tool chain, then fully integrated tool chain from a single vendor could be a good option. It's even better if this tool chain is already in use by one of the teams, or ideally with a few of them. If the answer is no, then the best of breed approach may be the most suitable one, as the teams are then able to make their own decisions and to make their own choices when flexibility is required.

Lauri (21:20):

That sounds very straightforward, but world isn't always very black and white, so there are always some gray areas that we don't quite know how to navigate. So let me ask this question, where are the risks? Where are the gray areas that you quite can't predict, but you would like to be aware before you start this kind of project?

Tuomas (21:43):

Migrations are always a risk, so you have to really pay attention how to keep the existing operations running while you are shifting to a new environment, so that needs to be coordinated. You should make the shift gradually, not as a big bang. You might want to start with new activities, and first, onboard them to the new tool chain. Once you have gained experience, then you start migrating the older activities as well. And you shouldn't forget the cultural aspects. People will react to the changes in different ways, so you have to take into account that tool choices are something that will affect the culture as well, and it needs to be taken into account.

Lauri (22:37):

You mentioned about the migration, and I do remember some of the business cases that we have calculated were such that, even though you would invest in platform and it would be a technology deployment and technology rollout project, but nevertheless, there was a migration component in the business case. Moreover, there was consulting included in that project so that you would have people with existing skills, how to do this automation consulting and how to migrate the work, that was also, I remember, part of that business case calculation, which is important to take into account. When you think about the business case and the net present value of the solution, it's not only, "Okay, this is the cost of licenses, cost of hosting, but it's also the training, the migration, the automation consulting", and so on, so on, so on.

Lauri (23:32):

We are getting towards the end of the conversation, and I mentioned in the beginning about this, Amazon's one-way door versus two-way door, which I very much like in the management style, that you are always conscious not to paint yourself in the corner, you're always conscious of making decisions that you know if they can be rolled back or not. So let me ask, how do you keep options open in the DevOps pipeline?

Tuomas (24:04):

With best of breed tool chains, you will always have plenty of options, because, like I said, each individual component that belongs to the system is fairly easily replaceable with an alternative. You can always add, of course, tools to a single-vendor system as well, and then make a shift towards a multi-vendor system if necessary along the way. So you can, in essence, take the core pipeline from a single-vendor, and then compliment that with others.

Tuomas (24:41):

But with single-vendor tool chains, obviously, in the beginning the assumption is that the vendor would offer you with most of the functionally that belongs to the pipeline. You have to pay, anyhow, attention to potential vendor locks here. If a single-vendor platform is chosen as the solution, and there are no other alternatives available, then, of course, you become quite dependent on the vendor and the way that they develop their solutions further. Naturally, the division is not that black and white. You will have vendor locks with the best of breed tools as well. And if you are not happy with a specific component or a part of an integrated tool chain, like I said, you can always integrate another tool to the pipeline, if necessary. Then you simply have two parallel solutions available.

Lauri (25:29):

Many, many years ago, I had a colleague who used to say that, in many cases, you effectively have two options. One is that you will distribute your eggs in multiple baskets so that if one basket drops then not all the eggs gets broken. The other option is that you put all the eggs in one basket and you will take really, really good care of that one basket. So then you will just make sure that nothing ever happens to those eggs, because you have already made your decision, they are all in one basket. Yeah, it may apply here as well.

Tuomas (26:03):

Yeah. So you have to either divide the eggs in multiple baskets, with multi-vendor solution, or then you have to make sure that the basket, the one basket that you choose, the single-vendor system, is robust enough right from the start.

Lauri (26:17):

Is there something else we haven't discussed and you think you absolutely have to put it out there?

Tuomas (26:24):

Nothing that I can think of, I think this was a nice conversation.

Lauri (26:29):

Indeed. Thank you for your time. And well, let me just say that I need to take some lessons learned from your running practice and try and see how exercising in the morning would fit for me as well. But so far it seems, at least for today, that I'm going to run in the pitch black.

Tuomas (26:45):

Yeah. I truly recommend you to do that. Yeah.

Lauri (26:48):

I'll take a look at that. Thank you for your time.

Tuomas (26:51):

Thank you.

Lauri (26:53):

Interesting, wasn't it? My takeaway from this conversation was twofold. One, if you go for a suite that satisfies most or all of your needs just now, make sure that it is extensible to help you forward when you come across its limits. And two, if you go for a DevOps platform, you always have your options open. Whichever way you go, I'd like to finish off by quoting our earlier guest, Henri Helakari, who said that, "Tools reveal shortcomings in your culture."

Lauri (27:28):

Well, that's all I have for you today. Stay safe and keep integrating the tools to deliver a seamless software production factory.