Knowledge Library
Welcome to your go-to hub for all things platform engineering. Dive into expert insights with our blog, explore in-depth resources in our library, tune into inspiring conversations on our podcast, and watch engaging videos packed with valuable tech knowledge.
Value stream management. If you’ve spent any time on the internet as part of your job in DevOps, it will have become blatantly obvious that there are many people out there who truly believe you should be value mapping your way to DevOps bliss.
Main takeways
- Value stream mapping is very useful and complements DevOps
- It needs whole organization buy-in to work
- It also requires plenty of time and brainpower
- VSM needs to be maintained over time
- No time? Do an initial VSM assessment and use it as a snag list
As a productivity technique stemming from Japanese manufacturing and closely tied into the lean management model, some organizations out there are old hands at value streams, mapping and managing for some time already. If that’s not the path your organization has taken already, however, it might still seem an unfamiliar (and dare we say time-consuming) way to spend your DevOps time.
So, is value stream mapping a DevOps essential, or simply a “nice to have - if you like that kind of thing”? We take a look.
Is value stream mapping useful in DevOps-first orgs?
Is it useful? That’s probably your first question and there is only one answer - sure, there’s no doubt - value stream mapping is very useful. DevOps looks to optimize business value and value stream mapping looks to find the problems with the flow of value. They are closely related and mutually beneficial. Value stream mapping is a tool that can help maximize and improve the contribution of DevOps.
Some thinkers in the field of DevOps feel even more strongly. Marc Rix, SAFe Fellow and Curriculum Product Manager at Scaled Agile, says that value stream management is THE most important tool in DevOps:
“Business value is the ultimate goal of DevOps, and value begins and ends with the customer. DevOps needs to optimize the entire system, not just parts of it. Flow should be Lean across the entire organization, and Value Stream mapping is a Lean tool” .
Seeing value stream mapping through the same lens as visibility will help sketch out exactly where it lies in your world of DevOps. The method is another way of seeing where all the blockers, hindrances, and obstacles lie on the road to providing a seamless journey from idea to finished product. Many of these blockers will be ones that can be solved or improved by applying DevOps thinking - greater collaboration, fewer silos, automation potential, and improved visibility to name but a few.
VSM maestra, Mary Poppendieck, gives a masterclass on the subject
Is VSM the right move for your organization?
While there’s no doubt that value stream management is very helpful to DevOps-first teams and organizations, there are one or two things that deserve attention before you charge ahead.
Much like DevOps aims to optimize the software delivery process from end to end, value stream mapping aims to chart it end to end. If there is limited buy-in across your organization, your results will be limited too. While both approaches are best carried out in a holistic way (across a whole organization), if there isn’t generalized take-up, DevOps can be applied wherever possible without ill effect. VSM, however, must be applied to the system in its entirety, or it is close to useless. Do you have this buy-in in your team? Without it, you may find yourself struggling.
Secondly, managing and mapping the value stream is no simple task. While there are apps, books, and videos to help you in your task, it remains a big job that gets bigger as your organization does. As an IT leader, you already have your hands full - do you really have the schedule - and mind - space to devote to the skillful maintenance of your value stream?
To map or not to map?
If you decide that value stream mapping is the right way forward for your situation, the actual mechanics of creating and managing one shouldn’t be problematic. The internet is awash with value stream mapping tools, plans, articles, and advice. There are books, videos, and even courses. You really won’t find yourself stuck.
Where the doubt will enter is in companies - perhaps smaller - that are unsure if they have the bandwidth or resources to complete and maintain the task along with their other responsibilities. At the very least, take some time to familiarize yourself with the theory behind it and some of the ways you might go about actually doing it in your organization.
While value stream management needs to be an ongoing process that takes account of changes over time, the initial completion of a value stream assessment can provide a good baseline and point of departure. The assessment can give you a list of areas or problems that need attention, many of which can inform the direction of your next steps in DevOps - sort of like a snag list for your organization.
Summing up
Value stream mapping and management is clearly an approach of huge value to most enterprises - and those that embrace DevOps solutions and tools have some of the best opportunities for solving the problems that it may reveal.
Even so, much like DevOps, VSM works best when it can truly assess an organization on a global scale, taking all the aspects that contribute or detract from value flow into account. If that’s not possible, either due to a lack of buy-in or resources, it may be better to sidestep the process in the short term, instead of concentrating on the changes you already know will have an impact, saving your VSM energy for a later stage where more stakeholders are able to appreciate the fact that to be truly impactful, both VSM and DevOps work best when there is organization-wide cooperation.
Interested in finding out more ways that you can help bring business value to your company via DevOps? Download our free ebook, DevOps Business Value: prove it or lose it.
{{cta('9794bab6-6c2f-4a7e-8f3f-7c90969b525d','justifycenter')}}
...
TL;DR
Infra Import, launched last week, marks an important milestone in the ability to use Cycloid to create infrastructure as code and industrialize deployments even when using legacy code.
The problem
Infra Import sidesteps the age-old problems that arise when trying to manage your infrastructures through your cloud provider’s console or - perhaps even worse - trying to create your own Terraform from scratch. The console can result in wasted effort, error, and infrastructure drift. It’s hard to scale and when your infrastructures get more complex, it just leads to more complicated problems. If you’re brave enough to create your own Terraform, your devs risk boredom and frustration. That’s if you’re even lucky enough to have a DevOps engineer willing to try - something that many organizations struggle with.
The solution
We’ve launched Infra Import as part of Cycloid. Based on our open-source tool, TerraCognita, it’s an IaC automation and project generator that allows you to manage your manually-deployed cloud infrastructure with Cycloid. It automatically creates StackForms, Pipelines, and your Terraform and .tfstate files.
You can see where we’re going, right? Because Infra Import does this job automatically, the DevOps you do have don’t need to spend their precious time on the job, and, well, if you don’t have many DevOps engineers, you can get the job done anyway. Not everyone wants to become a DevOps engineer and, even if they do, it’s not usually a speedy process. Thanks to Infra Import, however, this won’t be a problem for your organization, no matter where it is along the road to DevOps. You can help non-expert people start with Infrastructure as Code, ensure best practice is respected, and save time for the DevOps you do have.
Your existing deployments are back under your control!
We know you worry about governance, but here, there's no need for concern. Your DevOps/Infra team will always have the last word when it comes to the policies, roles, and permissions that govern your infra. They’ll have the governance they need and end-users will have the autonomy, flexibility, and simplification they want - and everyone ends up happy.
How it works
There are just a few steps between you and infrastructural bliss.
- Select your cloud provider and fill out the appropriate credentials to enable connection to the API. This will allow you to import your deployed infrastructure.
- Select which stack resources you want to import from your deployed infra.
- Name your blueprint and specify what catalog repository Infra Import should use to store the created stack.
- Enter the name of the project you want to launch, the config repository where the project configuration will be stored, and the location of your Terraform state file.
Your next steps
The best way to see Infra Import in action is to ask for a demo or a watch our demo video. Cycloid’s a multi-faceted, end-to-end enterprise tool - it's going to help you roll out a DevOps revolution in your organization. It makes no sense to give you access, a pat on the back, and leave you to your own devices for 30 days, so we ask you to get in touch so we can optimize your experience.
Infra Import helps you scale efficiently, in a reproducible and controlled manner, across all your environments - what’s not to love?! Getting in touch could be the best move you make today.
{{cta('4a329b1d-f8cc-40bb-83b1-b7fb231c5b30','justifycenter')}}
...
DevOps professionals are in demand. It’s not surprising when you think about it. DevOps is often seen as a silver bullet in the product development arena. It can help companies create higher quality products, go to market faster, and respond to customer feedback and competitive pressure more efficiently.
But hiring for this role is no mean feat.
What makes DevOps especially difficult?
What is DevOps, really? If we played a game of Family Feud and asked 100 CTOs, we’d probably get 100 different answers. It means different things for different companies depending on the business model, company culture, and goals.
As many companies have yet to define what they mean by DevOps, hiring someone to fit the role is tough. Even developers often don’t understand what is required from a DevOps job. That’s why people market themselves as DevOps experts but don’t actually have the skills to get the job done.
And if you’re only starting your journey towards DevOps, you’ll soon find that shifting to this model isn’t easy. How do you change the way you operate and bring together traditionally siloed departments without causing massive disruption to competitiveness and delivery?
Finding the right starting place
Much DevOps hiring goes awry because people are starting in the wrong place. It is especially easy when your organization doesn't already have a strong DevOps culture - it would seem that by hiring 20 DevOps engineers, you'd have a great starting point for a strong DevOps culture, right?
Wrong.
If you view DevOps as simply another job title instead of something that your whole organization (at all levels and in all departments) needs to embrace, then any new hires will have a limited impact.
We haven't investigated why it's hard to hire for DevOps yet, but we're already offering some solid advice - DevOps engineers don't make a DevOps-first organization, the DevOps mindset does. Work on that before hiring a single person and you might avoid the question "why is it so hard to hire for DevOps?" completely.
Almost half of HR professionals say they struggle to recruit DevOps engineers. Is this hiring struggle just a simple supply and demand problem? Or are there other issues at play that make it so difficult to hire for DevOps?
Here are some of the most common objections we’ve heard. Let’s take a look and see how many of them hold up under scrutiny.
Becoming a DevOps Engineer is hard
Companies ask a lot when hiring DevOps engineers. The skills often required for this role include:
- An understanding of QA processes
- Sysadmin expertise
- Programming skills
- Knowledge of the software development lifecycle (SDLC)
- The technical ability to build DevOps-friendly infrastructure
- Interest in staying up to date with new technology
It’s rare for engineers to possess all of the above skills; often they will specialize or have preferences. They also take a lot of time to learn. You can’t just recruit people fresh out of college, which narrows the field.
On top of that, DevOps engineers need soft skills, such as leadership, communication, collaboration, empathy, and problem-solving. It can be hard to hone these skills when you aren’t already in an organization that uses a DevOps model.
It’s very difficult to know how to recruit for DevOps
According to rumors in the industry, a recruiting firm compiled a list of people who have the necessary DevOps skills in a major city. There were only 40 names on the list. All of these people were already happy with their jobs.
Even a quick search for DevOps Engineers jobs on LinkedIn reveals 16,628 openings in the EU alone. This is what recruiters are up against when they try to hire.
It’s a competitive field!
Soft skills are also tough to recruit for. If you thought it was hard to find someone who masters programming, systems admin, and QA skills, try to add soft skills to the package. If you want a ready-made DevOps engineer, you need to pay through the nose.
But what if you haven’t even defined what DevOps looks like in your organization? Without a clear idea of what you need, you’ll end up creating job roles with imprecise requirements. Either you’ll get no applications as candidates don’t trust the job description, or you’ll end up with a ton of irrelevant resumes to sift through.
Traditional recruiting sites such as LinkedIn often won’t yield the kind of results you want. Even if you do find someone who seems right for the role and has the necessary skills, will they even respond to your cold approach? They probably already get more messages than they can handle from recruiters trying to poach them for their DevOps role.
Developers hate DevOps and don’t want to learn how to become DevOps engineers
Developers have very strong opinions about DevOps. There is no shortage of rants about the topic on Reddit!
Some common gripes include the worry that they won’t be respected as developers or will end up spending very little time coding as they just don’t have the bandwidth. Will they even be seen as programmers or will they be labeled “the DevOps person”? You don’t want to spend 10 years learning programming languages only to end up as a jack of all trades and a master of none, and the only go-to person in your company when it comes to product development.
One Reddit poster says, “DevOps is harder, more stressful, and requires a wider variety of "soft" as well as technical skills (including programming) than your typical front or backend developer role, but is somehow less respected by management.”
If that wasn't bad enough, don't get developers started on the topic of DevOps tools. Using a hodgepodge of tools and a messy technology landscape, DevOps engineers are under increasing pressure to build, test and deploy faster and faster as businesses look to reap the benefits of their investment.
As another Reddit contributor in the above thread explains, “you're stuck trying to contort these tools with their crappy DSL or YAML languages into something that could potentially be useful”.
Ah yes, the old tool contorting. Definitely, a situation you want to avoid...
What do DevOps Engineers Do and What Should I Look For?
There's no magic formula to explain how to hire a DevOps engineer. DevOps isn’t a specific role: it’s a way of thinking, a methodology, and a way of life. It unites people, processes, and tools. DevOps removes the old siloed way of working, the idea that a job or a problem is only the responsibility of one department. It requires collaboration and an end to anti-patterns, like the bus factor, Ikea effect, and ping-pong thinking.
DevOps roles are often lumped in with developer roles, but instead of imposing specific requirements such as needing X years of experience with certain tools or programming languages, instead, look for smart people. Search for candidates who take a collaborative approach, ones with a good attitude and work ethic. Take time to see if there's anyone already in-house that you can train up.
Don’t be lured into spending a lot of time and money trying to hire perfectly formed DevOps engineers - it's not always the only way. Remember that the more your tech team adopts DevOps thinking, the less you'll actually need to hire a whole army of DevOps engineers.
How can you move forward? Well, before hiring anyone, make sure you truly understand the motivation behind DevOps, then make as many moves as you can towards championing and encouraging it in all your tech team members, not just the DevOps engineers.
Eventually, when you decide you need a DevOps engineer, make sure you have the necessary framework and mindset to support them and ensure their job is more than just tooling. Commit to ending siloed departments and creating a truly collaborative working environment. Do all this and you might just be able to avoid becoming the subject of a developer’s wrath on a Reddit thread!
We hope we've given you some food for thought. To continue your journey, take a look at our free ebook, Upskilling <-> DevX Link: Why people are the key to your digital transformation, to learn how to keep the DevOps you have and attract new talent:
{{cta('d7401fb5-1767-46c5-a9c4-09dda5f8e850')}}
...
We sent our latest ebook, DevOps Business Value: Prove it or Lose it to Yannick Blondeau, CTO of Hotel Spider and longtime friend of Cycloid. We were really interested in what Yannick had to say, as he’s a man that finds himself in a pretty special situation. At the start of this year, he has promoted from tech lead to CTO of the hotel online distribution platform, giving him a unique perspective on both sides of the tech/c-level divide.
Would his personal experience mean he read the book differently to someone who is one or the other?
Let’s find out.
Cycloid: Thanks for joining us, Yannick! Did you have a chance to read the book?
Yannick: I did, thank you. It was really interesting. It would maybe be more useful for bigger companies where the conversation has to be more formal, but I enjoyed reading it. In smaller, more tech-focused companies, the conversation can be more organic, more natural. I’m lucky because many of my jobs have been with these smaller teams where communication is easier.
Cycloid: Yannick explained that in his experience, the larger a company gets, the harder it is to have those “water cooler” moments where you naturally ask questions and find out more. When teams are bigger, or remote, it can be harder to find those points of crossover and you’ll have to work harder to make connections happen more regularly.
Cycloid: So, the million-dollar question - what is the business value of DevOps?
Yannick: For us, it's the peace of mind, the reliability. As we started to roll out DevOps, we also rolled out infrastructure-as-code and it’s the standardization and control that they both offer that has really added value - in the form of speed and consistency - for us.
Cycloid: So, tell us - what’s the relationship between the average DevOps leader and the average CEO?
Yannick: Really, this depends on the kind of company more than the job role. If the company was founded by a tech person, there’s often not much difference at all - everybody is on the same level and understands the same context. You don’t need to explain, because everyone is a “tech” person.
Cycloid: Yannick’s right - not all c-suites are cut from the same cloth. Some modern start-ups and scale-ups are led by tech minds and people who have job titles like “CEO/Tech lead”. Move to an older, more established company, or one currently going through a digital transformation, and you can have multiple people on the executive team for whom the tech team is a true mystery.
Cycloid: What are the biggest “tech team vs.” silos in the average company? Is it the executive team?
Yannick: No, not at all in my experience. The biggest silo I have come across is actually between a company and their clients or the companies they are doing partnerships with - when you have one way of working and they have a totally different way, that’s where it can be hard to work together well.
Cycloid: You’ve been on both sides of the executive/non-exec wall - any insights from your unusual position?
Yannick: Yes, it’s actually been really interesting. As I have moved from the tech team to CTO, the team has also grown, so I’m leading a bigger team than the one I worked in. It’s a good time to be CTO, to have a more holistic vision of the company, and to be able to look at everything and point out the inefficiencies and problems and gaps and look to solve them.
Cycloid: Absolutely, it’s all about the headspace. When you organize things right and use the right tools, that’s exactly what DevOps can give you - the room to step back and look at things strategically from the bigger picture. It gives you a totally different perspective and hopefully one you can use to move towards growth and progress.
Cycloid: Can DevOps work without significant c-suite buy-in?
Yannick: Yes, to be honest, I think it can work even if only a very small subset of the business is actively applying DevOps principles. As they progress and see success from DevOps, it will spread into the company organically as they see the results and the benefits coming from that way of doing things. Even as people move in and out of teams, that knowledge will spread.
Cycloid: Interesting - and encouraging - to hear for people reading who are struggling with that widespread buy-in. Start thinking DevOps and the rest will follow!
Cycloid: So, to wrap things up, any DevOps business value stories you can tell us from the Hotel Spider trenches?
Yannick: Well, yes, one of the first things that comes to mind when I think about business value is the way we interact with our customers. We provide white-label solutions and since we use infra-as-code and DevOps, everything is so much easier. We can just plug our code in like a template, totally sure that everything will work properly and as expected. It saves so much time and worries, it’s definite value both mentally and financially.
If you'd like to read the same ebook that Yannick speaks about, DevOps Business Value: Prove it or Lose it, you can download it here.
{{cta('9794bab6-6c2f-4a7e-8f3f-7c90969b525d','justifycenter')}}
...
Ever feel that when it comes to the way the executive team and your tech team see success, they are so polarized they’ll never see eye to eye? We understand, but if it seems like business lies on one side and dev the other, it might be your DevOps thinking that can bring the two together.
How? Simply put, your metrics.
Can DevOps metrics really set the stage?
We know. Metrics are seen as things that build walls between people, not bring them together. They’re not cuddly-feely, don’t offer tea and cake, and are often met with confusion and fear.
Even so, if your executive team and tech team feel miles apart, you know that is simply the way it seems and not the way it actually is. DevOps is of major benefit to the whole company and most definitely the executive team. Their primary concerns are progress, profit, and competitiveness, and DevOps helps on all three fronts. What's keeping you apart is that they just don’t realize it yet!
DevOps will save you, just not in the most direct way possible.
By carefully choosing your metrics and data (and the way you present them), you will illustrate all that is positive about DevOps. Because you’re catering to a non-tech team, you’ll present this data in a very accessible way, allowing them to see where you are aligned, understand what you’re doing, and champion what you want to do in the future - once they realize how good it is for the entire company.
DevOps metrics - as easy as ABC?
Even within the DevOps team, the mere mention of metrics might make you balk. DevOps is notoriously hard to assess. There’s no formal ”DevOps” methodology and no checklist - so it’s hard to know how to judge its performance.
If you decide to strike out alone, it can be hard to find appropriate metrics but easy to go wrong. Some argue that DevOps needs fresh, custom-made metrics and frankly, many of us aren’t really in a place to do that for our own teams, let alone in a way that unites both DevOps and the executive team.
“When adopting DevOps, organizations should consider a new approach to identifying and implementing a DevOps measurement program.”
Peter Waterhouse, “Metrics That Matter”—Developing and Tracking Key Indicators of High-Performance IT
Do not despair.
By bringing the best of your DevOps thinking to the problem, you will choose metrics that naturally lean towards collaboration. If you are cultivating a silo-free environment, you’ll be aiming to work closely with the executive team - having metrics that include their needs from the very start saves time, breaks down barriers, and - let’s face it - makes DevOps look good.
Let’s take a look at how you might start creating these metrics and what pitfalls you might come across. Excellence won’t happen overnight, but DevOps metrics are a matrix for success that you can start building at this very moment.
Bad metrics - avoid these no matter what
It’s not accurate to say you need totally new metrics. Instead, you’re going to curate existing metrics, not create them. This data is already out there - there are concepts that exist, aspects that tools measure, and formulae that you can leverage. Your job is to pick the metrics that best illustrate what DevOps is trying to do for the wider business, and use that as a communication device when talking to the c-suite.
First, we want to give you a heads up. Some metrics out there suck. Here are our top 3 to avoid:
Vanity metrics
Vanity metrics are dangerous because they play to the hero coder, urging her or him to produce more, more, more! A go-go-go attitude like this will produce pretty graphs, but it will do nothing for collaboration, cross-function, or meaningful goals - no company aims to “produce more code”! Vanity metrics prize volume over actions that refine, streamline, and make agile, making them very dangerous indeed.
Conflict-encouraging metrics
Yikes, gamified metrics might be cool, but they pit teams against each other, comparing and contrasting achievements. They’re usually output-based and - gasp! - incentivize anti-DevOps behavior. All those great things that you want to encourage, like peer programming, cross-project collaboration, and communication, are endangered by metrics that encourage unnecessary work and blinkered behavior.
Old school metrics
Many leaders persist in utilizing incumbent metrics, like mean time between failures (MTBF) and the ratio of full-time equivalents (FTEs) to servers. But while these may have been useful in the past, they can work at cross-purposes with DevOps transformation today. After all, with faster delivery of services, some failure is to be expected. And as IT improves its responsiveness, the average time between failures may not be as useful as, say, a distributed representation.
Don’t get us wrong, it’s not because they’re old-school that we don’t like them. It’s more to remind you that some of the old reliables are solid, but they were more useful when tech teams moved differently and had different concerns. Take process metrics, for example, from ticket-based systems - more tickets processed is not a sign of DevOps progress! Likewise, many symptomatic metrics - like CPU and memory usage - are ok for troubleshooting, but no good for progress reporting. In general, output-only metrics aren’t as useful as they used to be.
DevOps metrics that work for everyone
So now that we have it clear that bad metrics help no one, and in some cases can even hurt, let’s take a look at the metrics and ideas that will help you, keep your devs happy, and facilitate your dealing with the c-suite.
Consider your audience
Any metric or, beyond that, most conversations you’re going to have in the workplace, can be divided into internal and external audiences. In broad terms, internal metrics deal with nuance, nitty-gritty, and detail. They let other experts on the same level as you know exactly what’s going on, why, and what you can expect to do next. External metrics, on the other hand, deal with the broad strokes and the big pictures. They deal with business outcomes and results - rather than how exactly we’re going to achieve those results.
One of the best tips we have for having these cross-team conversations is to always remember and respect your audience. You’ll do this not only by curbing or expanding on your information depending on the external/internal divide, but also by avoiding language that is music to your ears, but indecipherable jargon to somebody else’s.
You don’t always need the full monty
Whatever metrics you choose, ensure that the wider the audience, the pickier you are about the data you bring. Observability is key in DevOps, so we know that you have a full and fascinating array of data to hand, but if you’re addressing a wider audience, less is more. This doesn’t mean you have to shy away from data-led metrics, but always bringing a full ticket of data for every metric will complicate things and scare people away.
Instead, choose limited metrics to bring to external audiences and try to base them around the people/process/tools triad, which is clear and accessible. Over time, you’ll find which ones work well and which don’t, and you can allow them to evolve as a function of that. As time goes on, you’ll find common points over which departments can collaborate and, as long as they’re useful, you should always make space to let them in.
Better cross-department metrics
"The ROI analysis I think is still very early and immature around dev-ops, and we have lots of hypotheses about that”
Carol Carpenter, CEO ElasticBox
Better cross-department metrics really boil down to one thing. Whether it’s the executive team, marketing, or product, the bottom line is that you need to understand their point of view, and then use your DevOps-given collaborative skills to find the points of intersection.
Understanding the perspective of the "other" is a key skill in all collaboration, whether we're talking about negotiating with secretive forest tribes or convincing the boss to give you a fair chance.
In our E-book, DevOps Business Value: prove it or lose it, we go into some practical ways of understanding your executive team's perspective, but in short, it means really understanding what success means to them, the quickest way to that success, and watching out for problems that could prevent that success. Once you understand, there's a good chance you can talk to them on their own level.
Accept that it will be hard, for the moment, to prove actual ROI - the conversation is still very early. Instead, you're looking to collaborate with the exec team, using your soft skills to adapt and curate the metrics and data that you and your tech team get excited about. With a little careful editing, the c-suite will get excited about them too!
{{cta('9794bab6-6c2f-4a7e-8f3f-7c90969b525d','justifycenter')}}
...
According to the 2021 State of DevOps Report, 80% of organizations are failing to scale DevOps adoption, and that number hasn’t changed for 4 years. We took time out to talk to Cycloid founder Benjamin Brial about the path of DevOps and why it’s not always as smooth a journey as it could be.
“Look at the top 40 businesses in the world. There are only 3 or 4 left from the “old school”, the rest of them are the new school - GAFAM (the big five, Google, Amazon, Facebook, Apple y Microsoft). They’re up there because they ship as fast as possible”.
Move fast, or perish
With that, Benjamin opens the conversation about DevOps and business value. Ultimately, he concludes that although it’s often difficult to be the person introducing and championing DevOps in a company, those who hold strong and push forward will eventually succeed. Why?
“It’s a basic business need - new customers, and the ability to satisfy those customers. If you don’t deliver a new feature, your competitor will, and people will judge based on a feature to feature comparison.”
Compare the need to deliver new features with the speed at which your competitors can deliver those very same features, and you have a dog-eat-dog world in which only the fastest survive.
“The time to delivery has accelerated - there’s a study about developing cars, they used to take 10 years, now it takes 5. We live in a world of instantaneity - everything is now, now, now”
To do that, businesses have traditionally moved straight to the IT department and invested there. Ironically, that’s what has led to one of the main problems that solutions like Cycloid try to counteract: too many tools, too much complexity.
This surfeit of tools has two knock-on problems. First, that IT is seen as a cost when it should be seen as a value. If you don’t own your tech, someone else will come and take it - it’s the technical know-how that provides the value. Benjamin gives Booking.com as an example:
“Look at Accor and compare it to Booking.com or Amazon - Booking.com don't actually produce a product, something of value, they don't build anything but they own their tech, which is why, in the market, they are unbeatable.”
What's holding you back?
Secondly, Benjamin points out that even in the best-intentioned companies, there are always walls and silos, commenting “there is always a tech/executive silo. Cycloid’s own techs sometimes don't understand me, so it’s definitely a problem for others! Every misunderstanding slows things down, but business always needs it to be faster.”
We asked Benjamin why, if the need for DevOps was so plain to see, was it still so difficult to get buy-in in certain businesses?
“DevOps culture empowers people and that's not really how the enterprise world works. Traditionally, when you want to succeed in the enterprise, you concentrate on keeping your head down and not making waves. When you bring DevOps in, you’re fighting against tradition and against the status quo, the idea that "it's always been done like this"”.
Benjamin thinks it’s primarily a comfort zone problem - it’s not that executives don’t believe in the power of DevOps, it’s more like that it’s a brave new world, and those in the C-level aren’t natives.
The way forward
He points out that enterprises consist of structures that are designed to maintain silos, concepts like departments, politics, and accountability. It takes effort to do things differently and although executives are aware that they need to do things differently, it’s hard, they’re lost, and it’s complicated!
Even so, says Benjamin “there will be resistance, but you need to push because it's the only way forward”!
Despite the difficulties, there are a number of points that give DevOps fans the upper hand. Benjamin points out that DevOps is not really a question of hard skills, it’s oriented around soft ones. Now, this isn’t entirely unproblematic - soft skills are notoriously hard to recruit for - but when you do manage to get the right people, they’re uniquely qualified for the job - both DevOps itself and championing it in the greater enterprise.
There’s great satisfaction in being the one to do this, Benjamin says: “It’s nice to be part of something bigger, building bridges and getting rid of silos”. That self-same feeling of satisfaction is also going to be one of the things that help people push DevOps forward in their company.
A parting piece of advice from the Cycloid founder? Well, actually, he has a few!
“Get your execs to the same mental place as you - evangelize more, show them the advantages of DevOps, present the benefits, reassure them that it’s not a show job. There's this idea out there that DevOps means playing with lots of alpha tools, reinventing the wheel, or playing with new tech because its "really cool". Good DevOps care about efficiency and KPIs, and they care about evangelizing DevOps to others. These are the players you want on your team."
We couldn't agree more!
{{cta('9794bab6-6c2f-4a7e-8f3f-7c90969b525d','justifycenter')}}
...
A while back, I wrote an ebook to help people work on the one part of the DevOps puzzle you can't buy, outsource, or ignore - the DevOps mindset. During my research, I found an idea that really made me laugh - even though it probably shouldn't. It was in the middle of coronavirus lockdown though, so I have my excuses.
That idea was the bus factor.
The bus factor - variously known as the truck factor or the lorry factor - is a scenario or set of circumstances that are best avoided if you're part of a team. The idea is closely linked to redundancy, but in this case, the desired redundancy is people and not machines.
If you have a team where everyone has a job, but only one person knows how to do a specific job, then the absence of one team member will bring the whole team to its knees. This is the epitome of a single point of failure, and something that should be avoided at all times.
In case you're wondering where the term the bus factor comes from, we explained it in Plan Now, Win Later:
How do you calculate the bus factor?
Luckily, you won't need any complex calculations or audits for this one. Simply take the project in question and figure out how many people need to be absent before work cannot continue. If that's just one, then you have a bus factor of 1 - and that's a dangerous thing. If it's more like 3 or 4, then you're doing pretty well!
Why should you fear a low bus factor?
Think of the bus factor as one of the many canaries in the mineshaft that will alert you to the presence of unhealthy organizational patterns in your team. Since one of the mainstays of DevOps is butter-smooth organization and progress, you can see why the bus factor is something you want to increase.
We've also got a bit of bad news. Dysfunctional organizational traits rarely happen in isolation, so if you realize that you've got a terrible bus factor then there's a real risk that you've got other problems too.
Like what?
Well, are you sure you don't have a department of pingpong players? Definite that the Ikea factor, loss aversion, and the sunk cost fallacy aren't swaying your teams' actions? If you see one, check for others - this article is a good place to start.
Close, but no banana
Until now, we've really been looking at the traditional bus factor - the single person of failure. There are more variations of the problem, however.
The hero complex
The hero complex is, once more, a single person of failure, but the difference here is that rather than the professional skills they bring to the job, it's the integral role they play in the way the team thinks and acts. Very often, this person is known as "the rockstar" and, just like leather pants, that's not a good thing.
The rockstar might not be the only person who can do a job, but they are the single person that the rest of the team rely on, turn to, and trust. When they're absent, the team loses its mettle and direction, and ends up almost as useless as one that is missing its main dev.
Look in the weeds
Ok, so far we've looked at the problems a missing person might cause, but that's because that specific person and their knowledge, experience, or personality is missing. But it can also cause serious problems when the absence of a person means more mundane things. If John goes MIA, you might not miss his mediocre coding skills, but that essential password, missing 2FA, or release approval will bring your team to a halt nonetheless.
How to prevent a low bus factor
Ok, now that we've thoroughly scared you, you may want to know what specific aspect of DevOps thinking might protect you? Well, the number one thing that will protect you from this chaos is...cross project collaboration!
Cross project collaboration
Easy in theory, hard in practice, this is essentially what DevOps is all about, except instead of breaking down silos between developers and ops engineers, you'll most likely be breaking down the silos between devs and..other devs.
This kind of bus factor often rears its head in smaller teams, where there is only one frontend person, one Android developer, and one iOS developer, for example. When Daria the frontend dev gets run over by a bus, there is no more frontend for a while. If there's no contingency plan, that will hobble your app completely.
Now, it's true that Daria has been hired for her expertise in frontend development, and it makes sense that she's especially skilled at it. That said, ensuring the whole team can at least manage the basics across the stack means that easy tasks and jobs can keep moving, preventing a massive backlog from developing in Daria's absence.
So, this is fine in theory, but how to you ensure that your whole team has full stack experience in practice? Some teams are actually quite resistant to the process, while others are open but don't exactly know where to start.
Here's our best advice:
Get buy in
You'll be fighting a losing battle if your team is completely against the idea of working across the stack. Hopefully some bus factor disasters of their own will be enough to convince them to make a change, but if not, go slowly and try to lead by example, rather than pushing them in head-first.
Reduce barrier to entry
Make sure that across all projects, you've made it as easy as possible to get started. This can mean taking a look at the technical set-up and making sure it's very smooth, ensuring documentation is up-to-date and relevant, and generally keeping everything as simple as possible.
Lead by example
Obviously, you can help by leading by example and lending a hand where needed - just bear in mind that you can set all the examples you like, but if the practical things aren't in place, you'll be fighting a losing battle.
Dedicate time to other people's projects
There are various ways to approach this, but the most popular way is usually peer or group programming. Remember, at the start there's no need to be doing anything heroic with the code - just take the opportunity to fix a bug or get familiar with new code. Once people are situated and have set themselves up as they need, they'll find it much easier to go forward alone.
Reassign people to better distribute power
If you've detected a bout of hero worship on your team, consider redistributing your rockstar - or the people around her - to make it harder to rely on her for wisdom, leadership, or inspiration. People will soon see they can rely on their own judgement quite nicely.
Automation is your friend
Less a practical tip and more a general reminder about automation, once you have solid automation in place (helped by a tool like Cycloid, for example), the bus factor becomes much less threatening. Once it's in place, you won't need your rockstar - or Bob, John, or Daria - to ensure the job gets done.
Summing up
There's one overarching message you should take from this article - cross project collaboration is key. It's important in the world of DevOps, important in resilient tech teams, and key when it comes to increasing your bus factor.
Whether your bus factor is acceptable or not, get started on encouraging your team to get some cross-stack skills. Even if you've already got them, cross-project collaboration is an active initiative that needs to be nurtured, and this might be the perfect time to take another look.
Join 2,935 other proactive DevOps fans by signing up to the Cycloid quarterly newsletter.
{{cta('da7d1a6d-80dd-41a7-8811-0ffaef8d457e','justifycenter')}}
...
Francesc, a backend developer here at Cycloid and talented maintainer of TerraCognita, tells us what led to our recent launch of Terraform Module handling and what exciting developments it's paving the way for.
What did we add?
In the newest version of Terracognita (0.6.1) we added the ability to import a running infrastructure into a Terraform Module. This is a more manageable and standard way to structure your HCL.
Terraform Modules allow you to create a reusable and customizable definition of the infrastructure which will help you better define your standard infrastructure components. Also, the use of Terraform Modules is considered good practice and we always try to follow best practices.
How does it work?
Before telling you how it works, let's go over how it used to work so we can see the difference.
Before, we generated one HCL file with all the information imported from your infrastructure. To be honest, big configuration files are not manageable at all, and they're certainly not reusable, as what you see is what you get. To change it, you would need to dive into the generated file (potentially +500 lines of code) and change things manually or try to generate a module from it yourself. Honestly, that's not anyone's idea of fun and it can lead to errors in your IaC creation process. This is pretty silly when you bear in mind that the reason you'd use TerraCognita in the first place is to avoid mistakes in your IaC creation!
As we can see, this is not the best use case. Sure, it's usable and it gets you started in Terraform and HCL quickly - you would have the infrastructure in HCL and wouldn't need to write it from scratch. That said, it would require a lot of manual work to have something more refined and actually reusable.
Now, with the new version, we can do that work for you! The documentation explains how to do it but we'll go through it, the benefits it provides, and how is it done.
First of all, use:
--module module/path/name flag
...to enable the feature and we'll import everything as a module! Once it finishes, if you check your module/path/name/, you'll have a Terraform Module inside! The structure is the following:
- module.tf: is where the Terraform Module is declared and where it is configured
- module-name/: is where the module configuration resides (name being the directory you specified)
- module-name/variables.tf: is where all the variables that we define (so the module can be configured) are placed (more about that later).
name/
├── module-name
│ ├── autoscaling.tf
│ ├── cloud_front.tf
│ ├── cloud_watch.tf
│ ├── ec2.tf
│ ├── elastic_load_balancing_v2_alb_nlb.tf
│ ├── iam.tf
│ ├── rds.tf
│ ├── route53_resolver.tf
│ ├── route53.tf
│ ├── s3.tf
│ ├── ses.tf
│ └── variables.tf
└── module.tf
So, the first benefit is that we no longer have to import everything in one single HCL file. Instead, we do it in multiple separate ones based on the "category" of the resources. We can get this information from another OSS library we have named tfdocs, which, in a nutshell, parses the documentation from the Terraform Providers and provides a normalized output so we can check it in different places in the Cycloid codebase, like InfraView and StackCraft.
Now, back to TerraCognita!
This generate module is a bit raw - it's the default and most basic configuration that we provide and what it'll do is replace all the attribute values from your HCL for variables with the value that they had as a default of the variable and declare those variables into a variables.tf which will be inside of your module-name/variables.tf.
Then if you check the module.tf you'll see it has all the variables added to the Module block commented with their values, so you know which value they have by default. If you wanted to change them, you could uncomment and make the modification you need.
module "name" {
# aws_instance_front_instance_type = "t2.small"
[...]
source = "module-name"
}
The second benefit we see is that modules make modifying your configuration much easier, but wait, there's more...
We can make that module even better by adding --module-varibles path/to/file flag which will allow you to define a JSON/YAML file with all the resource + attributes that would be important for you to use in the module so only those specific ones (instead of ALL of them) would be defined as variables and added to the Module block
{
"aws_instance": [
"instance_type",
"cpu_threads_per_core",
"cpu_core_count"
]
}
This file format is basically a Key Values in which the Key is the name of the Terraform Resource and the Values are the list of all the attributes of that resource that you would like to import.
Conclusion
Using TerraCognita's Modules feature will help you better import your infrastructure into Terraform Modules. You'll be able to import in a more customizable way that will improve the reusability and configurability of your infrastructure. This provides an easy way to adopt Terraform best practice.
Stay up to date with everything coming from the Cycloid stable - sign up for the quarterly newsletter.
{{cta('da7d1a6d-80dd-41a7-8811-0ffaef8d457e','justifycenter')}}
...
Nikola, a front end developer here at Cycloid, tells us what led to our recent shake up of Roles & Policies, why what we had could be improved, and how we went about improving it.
Until recently, our Roles and Policies system used a one-to-one relation. What does it mean? It means that the user was able to assign only 1 policy for 1 entity without any link or hierarchy between those entities.
Why was that a problem?
The user had to give access to the project but also specify access to each pipeline belonging to that project. That wasn't a big deal for small projects, but as complexity increases, it becomes really cumbersome to scale and maintain. Another issue was that we were not able to create flexible complex custom user roles.How did we overcome it?
To solve the problem, we had to replace what we had with a new technology that we developed using REGO OPA (open policy agent). It provided us with scalability and opened the door for cool features we have already introduced and others that are planned for the future. One of those features is the ability to use globing. This eliminates the need to specify each resource or action and allows you to simply write policy like organization:**, which grants access to perform all actions under all resources.
How does it look now?
Now an organization can create highly flexible complex custom roles and even achieve role grouping by creating various roles and assigning them to a team. If we need to be more specific, the role can be created using system-defined actions and resources or/and with manually created actions. From a technical point of view, we now have clear ground and solid foundations for developing all the features we've planned for Roles & Policies - permissions scoping, enhanced globing and even greater flexibility.
Roles & Policies - the future
Our goal is to achieve a fully customizable and scalable solution that will enable enterprise customers to handle access to their resources. For example, as an admin user, I would like to give access to Project B and all its child entities by using globing and scoped permissions, avoiding the need to add permissions for each action on the entity manually.
One possible way of achieving this would be by the user creating a role that contains permissions to perform all actions on a specific project:
Action: `organization:<org_canonical>:project:*`
Resource: `organization:<org_canonical>:project:<project_canonical>`
That's just one example, but by moving to an OPA-based permissions system, we've ensured that there is a bright future for Roles & Policies. If you'd like to try it yourself, sign up for Cycloid's trial version, or check out the docs for more information.
Join 3,075 other DevOps enthusiasts by signing up for the quarterly Cycloid newsletter
{{cta('da7d1a6d-80dd-41a7-8811-0ffaef8d457e','justifycenter')}}
Can Platform Engineering address data center energy shortages?
In this eBook, we dive into how platform engineering can play a pivotal role in tackling the energy crisis faced by data centers.
The Art of Platform Engineering
This ebook will clear up any confusion you may have between Platform Engineering, Internal and self-service portals.
The Definitive Guide to GreenOps
This ebook will be your roadmap to success in a world where environmental responsibility takes center stage.
Guardians of the Cloud: Volume 2
Part 2 of our comic book sees the start of an environmental rebellion and attempts to use cloud resources more efficiently.
In It For The Long Haul: Platform Engineering in the Age of Sustainability
Enable smarter, more environmentally conscious cloud consumption decisions at every level of a business, and more efficient processes for your teams.
Guardians of the Cloud: Volume 1
Welcome to Guardians of the Cloud, a brand-new comic book series that takes you on an unforgettable journey to Cloud City – a place of endless innovation that harbors a deep secret.
Life in the fast lane: DevOps and hybrid cloud mastery
In this ebook, we show you how to roll out DevOps and hybrid cloud at the same time, while taking as few risks as possible.
IAC Migration for forward-thinking businesses
Read how to alleviate some of your infra-related anxieties with a simple tool. Here are the answers to some of your most burning questions.
Infosheet: hybrid cloud - bring it to the devs
Are you a team leader, tasked with bringing hybrid cloud to your team? We’ve put together 5 practical, actionable tips to make the rollout easier and the DevX smoother
Life in the fast lane: DevOps and hybrid cloud mastery
In this ebook, we show you how to roll out DevOps and hybrid cloud at the same time, while taking as few risks as possible.
Insight: Businesses need to start thinking about that DevX Factor
We believe that you should empower your existing teams to reach their full DevOps potential. How to deliver that DevX factor – insight by Rob Gillam.
Insight: How do you solve a problem like Cloud Waste?
Without supervision, running cloud expenses will add up and cost you success. Read about Cycloid’s solution to cloud cost estimation and monitoring – insight by founder Benjamin Brial.
Infosheet: Infra as Code by Cycloid
We believe Infra as Code is the only approach to software development that lets you scale safely and successfully, so let us soothe your concerns and lead you confidently into the wonderful world of IaC with this infosheet.
Infosheet: Governance with Cycloid
We know, we know. Governance isn’t cool, but it is essential! Cycloid builds it in from the ground up, so your experts have all the control they need, without cramping the style of the rest of your team. This infosheet explains our approach and what tools you’ll have at your disposal.
Cheatsheet: DevOps business value - make the case to the c-suite
It’s not the message that needs to change, it’s the way you deliver it! We’ve created an infosheet with a new perspective on sharing DevOps and tech metrics with a non-tech audience.
Ebook: DevOps business value: prove it or lose it
We’ve written this ebook to help tech team leaders create better, more productive relationships with the executive team, even if you’ve really had problems communicating in the past.
Whitepaper: Get Your Team Ready for Increased Automation
This whitepaper consolidates the 3 ebooks that make up the hugely popular Plan Now, Win Later ebook series and will show you how to lead your tech team into a DevOps-first future!
Ebook: Build a culture of operational safety
DevOps will help you scale, but scaling is dangerous if you have no safeguards in place. This ebook shows you how to keep your SDLC safe, no matter what.
Ebook: Make tools and schedules work with your team
The grind – or smoothness – of their daily work is what’s going to make or break your team. Set them up for success from day one – we show you how in this ebook.
We talk to Wilco Burggraaf, Green IT lead at HighTech Innovators, to shine the spotlight on the world of Green Coding – a transformative approach that prioritizes energy efficiency.
We sat down with Sean Varley, Chief Evangelist and VP of Business Development at Ampere to discuss the intersection of AI, cryptocurrency, and sustainable technology.
Donal Daly, the visionary founder of Future Planet, joins us this time and takes us on a compelling exploration into the realm of ESG (Environmental, Social, and Governance) strategies.
We talk to Guillaume Thibaux, Founder & CTO of Quanta.io, shining the spotlight on his visionary company that has pioneered a free solution to measure the environmental impact of a website.
Coming soon!
Up Next!
Keep an eye on this page to view upcoming episodes.
Next Episode Launch date: February 2025
Product demos
Cycloid Platform Engineering Demo Video
Improve developer experience, empower end-users and operational efficiency to increase time-to-market speed with Cycloid.
Improve DevX with Cycloid Platform Engineering
Cycloid Platform Engineering uses a simple user-friendly self-service portal and service catalog to empower your end-users.
Feature demos
Calculate the cost of resources before you deploy - Cloud Cost Estimation Tool
Cloud Cost Estimation is integrated within our developer self-service portal Stackforms to help you make the best cost-optimized decisions before you deploy.
Simple service catalog - Stacks
Preconfigure user-friendly Stacks and allow your devs to choose approved and suitable infra configurations from a custom service catalog that’s made to measure.
Reverse Terraform tool: Infra Import 2024
Infra Import industrialises your manually deployed infrastructure at scale by automatically creating Terraform files and generating IaC. Modernize your infra and future-proof your business with Cycloid.
