devopsy.kinsta.cloud

Category: Features

DevOps: It’s an Odyssey, not a Journey

It has become somewhat of a standard practice to tell people, “DevOps is a journey, not a destination,” which attempts to convey the fact that there is no end point that is set in stone. But a journey is a well-planned, point-to-point trip, while DevOps transformation is a messy, figure-out-the-next-steps-as-you-go trip.

So I propose we quit calling it a journey and start calling it an odyssey. This summer, when my mother takes her 10,000^th trip back to Germany, it will be a journey. She’ll start in Cincinnati, Ohio, and travel through a couple of states before finally making her way to Hamburg, Germany. That’s a journey. She knows where she is going, and the discrete steps along the way.

Her original flight from Germany? That was an odyssey. The trip went Berlin->Naples->Shanghai->Hawaii->California->New Jersey. Of all of that trip, only Berlin->Naples was a choice. Or, rather, the decision to go to Shanghai was a choice that required Berlin to Naples—very much in line with your DevOps choices making decisions for you along the way. And just like her family, you have no idea what your choices will be in a few iterations. They knew they had to go to Shanghai because that was the only port that would allow them in without visas, and they couldn’t get visas. After that? They knew they wanted to get to the United States or Australia (one assumes anywhere far from the insanity that was engulfing Europe and Asia during World War II), but how to get there was a total unknown. “First we start, later we finish,” was her father’s description of the goal.

And that’s pretty much what DevOps is: First you start, and in the fullness of time you will discover things you hadn’t even considered when starting that just make sense and improve your overall position. There will be fits and starts, wrong turns and massive improvements. It is an odyssey, and one that is designed—just like my mothers’ family’s flight—to make things better in the long run.

For example, the choice of Ansible or Puppet will make other choices easier. Giving teams more autonomy and increasing communications will make other choices more obvious. It will evolve into more than the first iteration’s goals would suggest, and that’s a good thing if increased agility and reduced manual intervention are the results.

So keep on that odyssey, but don’t expect a simple end. More likely, the identification and acquisition cost of future improvements will cause more than the benefit they introduce, and you’ll find yourself in a better place, ready to breathe a bit and let the market find new ways to improve all things DevOps.

Which is cool, because that should be your final goal: “We have improved so much that any improvements we could make right now would offer minimal incremental improvement for a significant cost.” At that point, your journey isn’t done, but you’re able to sit and take a rest, consolidate gains and assess future possibilities.

And until you hit that point, be excited that every iteration of DevOps is improving responsiveness and taking you closer to your goal.

Shameless plug: Read about my mothers’ odyssey here.

— Don Macvittie

April 3, 2018
Why Your Software Supply Chain Might Be Your Achilles Heel

Historically, cybercriminals are as lazy as they are innovative. They can come up with clever exploits and attack vectors, but they still generally focus on the low-hanging fruit in the most target-rich environments. Recently, attackers seem to have shifted focus away from directly targeting companies with strong security or a wealth of resources, instead going after weak links in the software supply chain.

No matter how many resources or how much effort you dedicate to securing your networks and protecting your data, it can all be for nothing if you trust a third-party supplier or vendor that is vulnerable. It is also true of your software supply chain, because the process of developing and deploying software offers opportunities that attackers can exploit.

The Case of Xcode Ghost

iOS devices are considered to be exceptionally secure. iOS is not impervious to attack or exploit, but it is more secure than the competing Android platform. Apps for iOS are also considered to be more secure, because Apple’s App Store is a “walled garden” with a stringent review process for an app to be approved.

A few years ago, however, it was discovered that more than 4,000 apps in the Apple App Store contained malicious code. Attackers had figured out how to leverage a weakness in the software supply chain to get past the gatekeepers of the walled garden.

How did they do it? iOS apps have to be written in Xcode. The Xcode software is provided for free, but the Apple servers are often slow—especially when trying to download from China, so developers often just search the web to get Xcode from a third-party site. Cybercriminals developed a malicious version of Xcode, then gamed the systems to ensure their version of the software would show up at the top of online searches.

Apps developed with the malicious Xcode software contained extra code that would phone home and provide the attacker a backdoor—and an opportunity to inject malicious code or execute commands within the compromised apps.

Low-Hanging Fruit

The Xcode Ghost incident is an excellent example of a software supply chain attack, and a perfect illustration of attackers going after the low-hanging fruit. iOS is relatively secure. The Apple App Store is protected and apps are reviewed to ensure they meet strict criteria. So, instead of trying to go after Apple or iOS, attackers figured out how to strike the platform used to develop the apps and sneak in through the back door.

I spoke with Ryan Olson, Intelligence Director for Palo Alto Networks, about the rising threat of attacks on the software supply chain. He explained that attackers know that when they are going after a hard target that would be difficult to defeat directly, there is a better and easier way: Just figure out who they trust and go after the low-hanging fruit.

This becomes a potentially larger issue in the context of DevOps and automation. The recent NotPetya ransomware was propagated through a malicious update. If your systems or software are configured to update and/or deploy automatically, a software supply chain attack can be in the wild and compromising your applications or data before you know it.

There are tools available to scan images, applications or containers before deploying them, but they typically test for known vulnerabilities or overt crashes or conflicts. They are not designed to look for latent backdoors that might be buried in the code.

Olson recommends that you start taking a closer look at the software vendors you rely on. It is important to understand how they are securing and protecting their code—because their weaknesses expose you to threats by virtue of the trust you give them and their apps.

— Tony Bradley

April 2, 2018
DevOps Careers: Report Examines What It Takes To Be an SRE

Do you want to be a site reliability engineer, or SRE? Sixteen years ago, the role didn’t actually exist, but now you can find more than 1,000 opportunities for a career as an SRE on LinkedIn. Before you decide if you want to explore such a career, though, you should check out the new survey from Catchpoint, which examines the role and what exactly SREs do.

Catchpoint launched its survey in January with the goal of determining what exactly it means to be an SRE. The survey takes a closer look at the types of organizations, skill sets and organizational cultures in place where SREs work. Catchpoint wanted to build a profile of the SRE role and determine whether there is a core set of principals or skills common to the SRE role.

The report includes responses from 416 participants representing a range of roles, industries and company sizes. Nearly 4 out of 10 respondents actually identify as SREs. More than half work for companies in technology-related industries, and more than 40 percent indicated that they work for a software-as-a-service (SaaS), infrastructure-as-a-service (IaaS) or other as-a-service (XaaS) provider. More than 50 percent represent companies with at least 1,000 employees, while just under 40 percent are from larger organizations of 5,000 or more employees.

What is an SRE?

The SRE role originated at Google in 2003. The SRE straddles the line between the “Dev” and “Ops” sides of DevOps. SREs foster collaboration, productivity and software performance and—ultimately—gives developers greater responsibility for the performance of the applications they produce.

SREs typically both write code and support existing systems. Nearly two-thirds of SREs report they are deploying code daily—with almost half indicating that they deploy code multiple times per day. According to the report, most SREs report to software engineering despite the fact that a large percentage of SREs actually come from an IT operations background.

Coding skills and a solid knowledge of IT operations are both valuable resources for an SRE, but there are also a variety of “soft skills” that seem to be crucial to success. Problem-solving, teamwork, composure under pressure and strong written and verbal communications regarding incident resolution are all necessary to be effective as an SRE.

Novices Need Not Apply

The Catchpoint survey contains some bad news for fresh college graduates looking for their first gig, and excellent news for experienced IT professionals: The SRE role is not an entry-level job. Eight out of 10 SREs have a college degree and have worked in IT for six or more years. A college degree in computer science or information technology isn’t necessarily a requirement, but 73 percent of SREs did, in fact, get degrees in a technical field of study.

Although a majority of SREs surveyed report to the software engineering department, most come from an operations or infrastructure background. Just under 65 percent of survey participants reported that they held a role as a sys admin, while only 53 percent previously held a role as a developer or software engineer.

To learn more about the site reliability engineer role, check out the full 2018 SRE Report from Catchpoint.

— Tony Bradley

March 30, 2018
DevOps: What a Wonderful World it Would Be

The promises of DevOps are clear. They offer faster iterations, allowing ops to keep up with agile development and make an IT organization more responsive to business needs.

DevOps doesn’t make less code. It doesn’t reduce configuration files. It doesn’t eliminate deployment issues (though it might reduce them). It doesn’t eliminate testing; indeed, it creates more if Agile and DevOps are taken to their logical conclusion: More testing, earlier. DevOps doesn’t reduce the need for security.

In short, it doesn’t reduce workloads. It might automate some of them, freeing up man-hours, which is absolutely a positive result—one of the more positive results, in my opinion. But it also introduces the overhead of the DevOps toolchain, so some of that automated freed-up time is already spoken for.

And automation of testing (for example) is something that’s been around for decades. The first UI-based automated testing system I recall was Microsoft Test. I managed a team that used it extensively to automate test runs of the software we delivered to financial services. It worked well, and there was much gnashing of teeth when Microsoft discontinued the product.

The same is true of most of the time-saving benefits of DevOps: We’ve tried them before, but DevOps approaches them from a different perspective—and, in many cases, a more sustainable perspective.

I’m a DevOps aficionado, make no mistake. The reason I’m stressing what it won’t do here is because misperceptions drag it down. Don’t go into it looking to reduce costs, because at least in the short run you won’t. Don’t go into it looking to save work, because at least in the short term those savings will be minimal. Going into it for the wrong reasons means the things you are measuring will ultimately look like failures, even if all the good DevOps offers is reaped.

Instead, go into it looking to be more responsive. Go into it looking to beat your competition to market. Go into it looking to increase communications across the team. Delve into DevOps for the right reasons, and you’ll be measuring the right outputs.

And remember, it is an iterative process. Don’t overstate expected benefits on the first pass. Low-hanging fruit makes it look as if DevOps will do a lot of things, but low-hanging fruit often has tight ties into firmly rooted trees, making it harder to grab than originally thought. Use a measured approach and look for consistent improvements. In some organizations those improvements might be small at first. But use your knowledge of the organization and application portfolio to create a measured success plan.

Reaping the benefits is worth the change DevOps brings. The ability to tell a line-of-business leader that the new functionality they are considering could be mocked up and ready for review in a week or two is a huge benefit to the organization. And it doesn’t hurt at all that such responsiveness will raise the rest of the organization’s opinion of IT.

So it is a wonderful world, if your goals are the right ones.

— Don Macvittie

March 20, 2018
The ‘Blockbuster Effect’ in the Age Of Automation
Saying that new jobs will always be created to replace those that have been eliminated by automation is a mechanism for avoiding a real problem that’s lurking on the horizon.

In 2004, at the height of its popularity, Blockbuster Video had more than 9,000 stores and employed more than 80,000 people worldwide. About 50,000 of the total workforce was employed in the United States. Going down to Blockbuster to pick up a movie was a Friday night ritual for many, this writer included.

Blockbuster and other video rental stores, along with the advent of affordable Big Screen TVs, were significant contributing factors in the growth of the home theater. People now had an alternative to $10 movie tickets and battling weekend traffic to get to the cineplex. An entire family could view a recent movie in the comfort of their own home for about $5. The only thing that was needed to complete the movie going experience was the popcorn, which frugal families bought at Costco by the caseload. Those who were less thrifty could buy a box of microwave popcorn at the checkout counter of the video store. The $25 cost of a Friday night date was reduced to roughly $6.

Blockbusters kept people on the couches and out of the movie theaters. Television had already put a damper on movie-going. In 1930, 65 percent of the population went to the movies once a week. By 1964, the number dropped to 10 percent. Despite the introduction of 3D projection technology and movie theaters offering added features such as in-seat dining, movie attendance is now at its lowest point since 1992.

Blockbuster was a transformational business on the entertainment landscape. Today, the company is gone. Streaming technology combined with an “all you can eat” subscription model killed it. (See Figure 1.)

Figure 1: As Blockbuster stock declined, Netflix’s grew.

Just as Blockbuster did away with the need to go to a movie house to see a film, Netflix, Amazon and other video streaming services did away with the need to leave the house to get the evening’s entertainment. America stayed home and enjoyed movies on the internet for a fixed monthly fee. Blockbuster went out of business.

Netflix employs around 5,500 people with gross yearly sales of $11.69 billion. Blockbuster’s gross sales in 2004 were $6 billlion. It’s astounding that Netflix does almost twice as much business as Blockbuster did at its height, with less than 10 percent of the Blockbuster workforce. Such is the benefit of automation.

Whereas Blockbuster needed to staff a store in every neighborhood to do business, Netflix and other streaming services work from a central, virtual location without the added expense of redundant staffing. Blockbuster had 9,000 cash registers to man. Netflix has one, which is run by some sort of AI.

So, where did all the out of work clerks and store managers go? Hopefully, they went on to other jobs, maybe ones that were far better than the day-in, day-out tasks that go with processing video cassette rentals. After all, that’s the conventional wisdom: There will always be new jobs to take the place of the ones eliminated by automation. But, let’s face a cruel truth: It takes a lot more knowledge and skill to work on video delivery at Netflix than it does to check out customer purchases at Blockbuster. And Netflix requires fewer people to make the business go. Would a Blockbuster employee in Sioux City, Iowa, have the skills and mobility necessary to go on to to work at Netflix in Los Gatos, California? Seems pretty far-fetched.

Right now, things are pretty rosy in terms of the economy. So the conventional wisdom prevails: As automation eliminates one job, another new type of job takes its place.

Yet, there is another way to look at it. There are good arguments to be made:
- As automation eliminates jobs in the modern world, new jobs for humans will NOT be created at levels required to keep a workforce fully employed. Rather, AI will do more and require less.
- The lead up to large-scale unemployment will not be slow. It will happen fast, over a period of a year or two. And, it very well might happen within a decade rather than decades in the future.
Blockbuster’s demise came about pretty quickly. The company was at its peak in 2004. Six years later it filed for bankruptcy with $1 billion in debt. The music retailer Virgin Megastore closed its last North American store in 2009, a year after music streaming Spotify went public on the internet. (Spotify generated $3.8 billion in revenue in 2016 with an employee count of 2,162.)

Productivity due to automation continues to accelerate. In the early 1980s, it took 10.4 man-hours of labor to make a ton of steel. By 2014, the number was down to 1.9 man-hours per ton. The increase in productivity is due to increased levels of automation (think: robots). Given the choice between buying a machine and hiring a worker, companies are more likely to choose the machine. Thus, it’s entirely possible to imagine that the day when a few humans will be supervising the work of many robots making steel is close. Not too soon after that, a single human will be supervising an entire robotic workforce. Then, finally, as AI continues to improve and further dominate the production landscape, no humans will be required. The robots will supervise themselves.

How far off in the future is this time? Dunno. But I can tell you that robots are now assisting with surgery on humans. How long will it be until one surgeon can use automation to do the work of 10? Then, how long will it be until AI can do surgery unsupervised, five years? Ten years? Only 10 years ago driverless cars were still on the test tracks; today they are roaming the streets of Mountain View, California. An autonomous robot with a scalpel is no longer the stuff of science fiction. Once AI can do surgery unassisted, where will all the displaced surgeons find work? Maybe a few will go into research. What of the others?

At one time there were 200,000 horses in the City of New York. They provided the labor for a good part of the city’s transportation system. Today there are fewer than 1,000 horses. Cars, trucks, planes and trains have taken over. There’s no benefit to employing a horse when a car can do the work better. As General AI continues to develop and improve its ability to connect the dots as only a human can, how long will it be until the labor of most humans is not needed? What will it be like when there is no benefit to employing large parts of the human population because a machine can do the work better? Yes, the ramifications are scary. But, the possibility needs to be considered. The sad fact is that few people are considering such a scenario, let alone coming up with ways to address the impact on the horizon. Saying there will always be employment for humans is an avoidance mechanism, particularly given the fact that modern machines are going beyond purely mechanical labor and doing more thinking work.

In 1990, people thought there would always be movie rental until there wasn’t. In 2000, people thought there would always be a Virgin Megastore until there wasn’t. Today, Sears keeps closing stores. It will soon be gone from the face of the earth. Yes, Amazon is opening brick and mortar stores. This might be good news. But the fact that these stores are highly automated and have few employees cancels out the good feelings of the moment.

These days when a company comes to an end, it’s not a drawn-out process. It happens fast, over a period of a year. Many of the people left behind are confronted with low-wage, “show up and do it” jobs. The more educated have access to a pool of better paying work that comes with an excruciatingly steep learning curve. Whether the job is low-wage retail work or high-paying tech work, each worker is—or will be—competing against AI-powered automation that can—or will—do the job better.

It’s not a pretty picture. But it is one that can avoided if we decide to think about alternatives and put those ideas into action. Sadly, there are more people thinking about how to get to Mars than solving the problem of unemployment on a massive scale due to the proliferation of industrial automation powered by general AI. The problem is that we still seem to be stuck at, “There will always be jobs to replace the ones eliminated by automation.” To say otherwise is deemed Cassandra talk. Maybe so. But to not give the problem consideration is beyond folly. It’s a danger that will exact a heavy price from everyone who has to work to earn a living.

— Bob Reselman
March 19, 2018
DevOps Isn’t Getting Cloud Security Right (and What Can Done About It)

The song title of Billy Joel’s 1977 hit, “Get it Right the First Time” aptly describes what DevOps teams need to take to heart when making the jump to the public cloud. But in most cases, security is lacking in the pipeline when making the shift—and a change in DevOps culture and mindset is necessary to “get it right the first time” for cloud security, according to McKinsey analysts.

It seems commonsensical to make sure adequate security protocols are extended to the DevOps pipeline before migrating to the public cloud. But in practice, statistics tell a different story.

According to analyst firm McKinsey, a full 78 percent of more than 100 firms recently surveyed are not reconfiguring their security tools when migrating to the cloud. Similarly, most security standards in place among the enterprises listed in the survey are non-sustainable for cloud networks.

“There are, of course, many security configurations for a public cloud for DevOps that need to be in place,” said James Kaplan, a McKinsey partner and cybersecurity lead. “Creating your server image in a public cloud can create many vulnerabilities [compared to in-house data centers].”

Security improvements will obviously need to be made on an industrywide scale in the near future as more companies embrace the cloud for DevOps. Currently, only 10 percent enterprises McKinsey surveyed have ported more than 40 percent of their workloads to the cloud. Within three years, that percentage is expected to jump, as 80 percent plan to migrate more than 40 percent of their workloads to a public cloud platform.

Culture Lag

At issue is how DevOps teams’ cloud projects very often remain straddled by security practices dating back to the 1990s.

“Most DevOps security is still with a ticket-based model,” Kaplan said. “They just called Joe in security and asked him to do x, y and z.”

Porting legacy infrastructure and operations to the cloud can also be problematic. A startup, for example, might make the jump more easily than a 30-year-old Fortune 500 company with data centers located in the North America, Europe and Asia. “It’s one thing if you’re building greenfield, such as creating a video streaming service from the ground up,” Kaplan said. “It’s much tougher to go to an agile DevOps cloud platform world if you are dealing with 30 years of legacy applications, eight mergers and all that type of good stuff.”

The Big Meld

Cloud servers can be fired up and ready to use in minutes. But it can take weeks before standalone security departments catch up. This might mean waiting on a security team to manually complete vulnerability scanning, penetration tests and firewall installation before cloud deployment. Or, in the worst case, these steps remain incomplete, leading to relatively easy-to-exploit vulnerabilities on the public cloud.

“DevOps cloud security requires particularly high levels of sophistication and capabilities, as well as agility,” Kaplan said. “There has also traditionally been less focus on speed.”

The solution is to converge security with the DevOps from the outset ahead of cloud development. In this way, security controls, reviews and deployment are integrated with DevOps, to create DevSecOps for the cloud migration process. This heavily involves developing APIs for security automation, Kaplan said.

Implementing DevSecOps also requires investments in training and culture. This consists of ensuring DevOps teams receive additional training to ensure security is integrated into every step of development work and for developers to maintain security support once the switch to the cloud is complete, Kaplan said. Training ensures DevOps team members have working knowledge of security APIs and orchestration technologies, and are eventually able to create new security APIs for DevSecOps, Kaplan said.

The end result is that cloud deployment remains agile, as it should be. Cloud migration is done more swiftly and efficiently compared to traditional security models, once the DevOps team has acquired the security knowledge it needs, Kaplan said.

“DevOps teams really need to expand their purview to think more about security. They must create more rigor around the security services and how the developer journeys should involve security,” Kaplan said. “And they then need to think about how to incorporate those security APIs into the application scripts for infrastructure APIs, capacity scaling and what have you.”

— B. Cameron Gain

March 15, 2018
Enthusiasm for DevOps Greater Than Actual Adoption, Survey Shows

When it comes to DevOps practices, adoption continues to lag intention by quite a bit.

GitLab recently surveyed some 5,300 software developers and engineers from mostly small and medium businesses around the world. The survey examined overall attitudes and perceptions around the state of DevOps, with a particular focus on uncovering any disparities that might exist between developers and IT management.

The responses showed that many organizations are sold on the idea of DevOps, especially those who have implemented it. Sixty-five percent of the developers polled felt that using a DevOps workflow would save development time. An even higher 81 percent of managers shared that same sentiment.

Organizations with an integrated DevOps strategy reported a high correlation between DevOps practices and overall team productivity. Development teams that deploy code on demand and spent more than half their time on new projects, for instance, had twice the rate of DevOps adoption compared to lower-performing teams. Higher-performing teams also generally considered automation of the software development life cycle a top priority and had access to better tools.

Yet, the number of organizations in the survey that have actually implemented DevOps practices was far smaller than the otherwise enthusiastic support for it would suggest. In fact, only 23 percent of the respondents in the survey identified their team’s methodology as following a pure DevOps model. Thirty-five percent described their DevOps culture as being somewhat established.

The low adoption rates are somewhat at odds with Forrester Research’s prediction about 2018 being the “Year of Enterprise DevOps” and may reflect the global nature of the survey base and the fact that many respondents were SMBs. Forrester found DevOps adoption to be around 50 percent when it conducted a survey of its own of 237 DevOps pros last year.

GitLab’s survey found that while developers view DevOps as critical to software development life cycle, many have not implemented a DevOps workflow. Similarly, while over 95 percent of the survey respondents placed a high value on collaboration and 81 percent felt that such collaboration was easy to achieve, 25 percent said they did not have enough visibility into operations, security and production. And 42 percent reported unclear directions as one of their biggest challenges to getting work done.

Culture continues to be a big roadblock. “It’s hard to get Dev and Ops to work together in a cross-functional way,” said Mark Pundsack, head of product at GitLab. “That challenge can be exacerbated by tooling. Disjointed toolchains lead to disconnected processes and barriers to communication that get in the way of working together.” Many developers in the survey reported using at least five tools to get their job done.

Nearly 6 in 10 of the survey respondents (58 percent) pointed to ingrained practices as their biggest roadblock to adopting new tools and practices, while 50 percent blamed an inherent resistance to change.

Interestingly, remote employees tended to have a more favorable outlook on how things were going with DevOps, with 67 percent saying they had good visibility into what others in the organization were doing compared to 57 percent of on-premises teams.

“DevOps culture is clearly important to achieving high performance,” Pundsack said. “For managers … the survey identified the top challenge in getting work done was unclear direction and managers should be able to play a role in fixing that.”

The apparent gap that exists between intent and adoption was not the only surprise in the survey, Pundsack said. Also unexpected was the extent of the discrepancy between how executives think their teams are operating, and what developers are actually saying. When asked how often they deployed code, 47 percent of managers were under the impression their organizations were deploying multiple times a day in contrast to the substantially smaller 39 percent of developers who said the same thing.

That one area aside, though, developers and IT manager seemed better aligned on other issues in the Gitab survey. For example, more than three-quarters of both developers and managers feel they are set up to succeed and about one-third of them felt that they deadlines they have to deal with are fair.

GitLab’s survey showed that most organizations expect to invest in continuous integration and continuous deployment tools in 2018, with nearly half strongly agreeing that CI can help speed up the development process.

“CI can help alleviate blockers in the development cycle such as removing the manual process to verify code before deploying,” thereby allowing development teams to have a faster and more effective feedback cycle, Pundsack said.

— Jai Vijayan

March 13, 2018
DevOps Chat: Concurrent DevOps with GitLab CEO Sid Sijbrandij

In this DevOps Chat we speak with GitLab CEO Sid Sijbrandij. Sid has guided GitLab as a co-founder to the heights of the DevOps market. Joining Sid and me is Ashish Kuthiala, who recently joined GitLab. I have always been impressed with the completeness of GitLabs’ vision of the DevOps toolchain and what the company wants to offer. Sid’s vision for this is something he calls Concurrent DevOps. You will hear more about Concurrent DevOps in our chat, as well as in the months to come.

Another thing about GitLab is is an open source-based company, which allows for a lot of transparency. With hundreds of thousands of organizations using GitLab and thousands of paying customers, GitLab is a great example of a DevOps success story.

As usual, the audio of our conversation is immediately below, followed by a transcript of our conversation.

Audio

Transcript

[su_pullquote align=”right”] [su_custom_gallery source=”media: 120255″ link=”post” target=”blank” width=”200″ height=”200″ title=”never”]Sid Sijbrandij
Sid saw the first ruby code in 2007 and loved it so much he learned to program and made this his profession. Before that he was engaged in various businesses, from selling programmable infrared receivers to starting a recreational submarine company. He is always looking to publicly document an answer or to make a process more efficient. He was never good at sports but tries to make it up in quantity by hiking, sailing, skiing, snowboarding, speed skating, dancing Zouk, squashing, and running. In love participating in conversations on Hacker News, and reading Marc Andreessen’s tweets (now that Marc stopped this greatly increased his productivity).[/su_pullquote]Alan Shimel: Hey, everyone, it’s Alan Shimel, and it’s time for another DevOps Chat. Our DevOps Chat episode today is gonna be all about GitLab, and we’re joined by two GitLab folks. First joining us is the co-founder and CEO of GitLab, Sid Sijbrandij, and I hope I did that justice. Sid, welcome to DevOps Chat.

Sid Sijbrandij: Thanks for having me.

Shimel: Thank you. And joining Sid and I is a friend of mine, recently joined the GitLab team, Ashish Kuthiala. Ashish, I didn’t mess that up too bad, did I?

Ashish Kuthiala: No, you didn’t. No, that was perfect.

Shimel: Alright! Well, one of the nice things about tech is, I get a lot of experience. Not a lot of Smiths in the group. [Laughter] And as I said, this is Alan Shimel, and we’re here with DevOps Chat.

So, guys—GitLab. You know, first of all, Sid, I’m sure you’ve probably heard this before, but I’m sure there are people in our audience who still have to ask themselves, “GitHub, GitLab,” right? And as silly as it sounds, they may confuse them sometimes.

So, let’s set it straight in terms of GitLab. Sid, you co-founded it. What exactly is GitLab and how does it differ, let’s say, from GitHub, and we’ll go from there.

Sijbrandij: Yeah, so GitLab started off as an open source alternative to GitHub, where you could have Git repositories, do version control, do some issue management, and it’s now grown a lot as a company and as a project. We now do the whole DevOps life cycle. So, anything from planning to rolling out what you’ve made—CI/CD, packaging, monitoring—all in a single application.

Shimel: Great. And I think you’re being modest, actually. GitHub is certainly—when you say branched out, it’s branched out, I mean, from what I know, and I’m no expert, obviously, the breadth of the vision is pretty dynamic. So, congratulations with that.

Sijbrandij: Thank you.

Shimel: Ashish, you were—thank you. Ashish, you recently joined GitLab, and why don’t you give us out, what’s your position there?

Kuthiala: So, Alan, I think you and I have known each other for a while, and I am very passionate about the promise of DevOps, especially at large scale enterprises, right? Not smaller teams or not those who had the luxury of building out their infrastructure and teams to adopt DevOps and realize the promises of that.

We still a lot of the larger enterprises struggle with adopting and realizing the promise of DevOps as it is. I mean, a lot of them are achieving results, but a lot of them are still in the journey and trying to figure out how to get there.

So, and I had heard about GitLab, I knew that they were building out a solution for this, but I think it was in the last DevOps Enterprise Summit, you, I, and Haydn ran into each other. And I started talking to Haydn and I learned more about the company, and I think it’s just the right product at the right time. Because if you look at all the challenges that exist in the big enterprise, there’s massive transformation needed, and there’s several things that prevent this from moving forward at the speed that everybody would like, whether this is different organizations within the large organizations to get them to collaborate together, whether this is stitching together the different toolset chains to kind of make this seamless.

And I think GitLab has really built something from ground up that addresses this problem. And the good news is that the velocity at which we are adding functionality, we are adding the needs that need to be addressed. Because we are an open source company, we are completely open and transparent, right? We gather input from everybody, a road map is opened. We take the input, we take contributions, and we build the right thing for solving today’s problems. And as needs change, I see this model as something that can really adopt to that, right?

Because the world of DevOps is changing very rapidly, and often there’s a fear of getting locked in with a vendor, too. With our solution, I think the openness of it and the direction it can go to solve problems as they change is a great promise, and we’re already solving a lot of problems. So, that was a big thing for me, you know, that I considered in joining GitLab.

And the other thing is the culture and open transparency that Sid and the company have built in the company. It’s just phenomenal for me, right? I mean, that was just an eye opening model of how everything we do is open to the world. It’s open within the employees. Anybody can contribute, anybody can look at everything we do and how we move forward to help our customers.

So, these two are the main things for me that really inspired me to join GitLab.

Shimel: Great. So, Sid, I’d like to come back to you. Certainly, we can all have vision, but execution is what kinda separates winners from losers in the market. And I’d like to ask you, as the CEO, what’s the secret, if you want to share it with us, right? How do you translate this vision that attracts someone of Ashish’s quality and character and then translate that into an execution that actually translates to success in the market?

Sijbrandij: Yeah, I’d love to talk about that. We’re biting off a lot, so I think we’re now—GitLab offers a great solution for 10 different product categories. So, that’s massive. There’s a lot of engineering effort. For example, we have a CI/CD team that is just 10 people, and that they have to compete with people that are 100 times bigger. So, how do they do that? First, they’re just selected. GitLab CI is the leader in this space. There’s GitLab CI on the top right and then whole lot of nothing.

Shimel: Mm-hmm.

Sijbrandij: So, how do you do that with 10 people? Well, there’s a couple of secrets. The first one is—you don’t do that with 10 people, you do that with 1,800 people. So, we’ve got over 100,000 organizations using GitLab, and over 1,800 people contributed to the product. So, in the release that will go out in a week from now, there’s not just 1 contribution, there’s not 10, there’s 93 features that people contributed that aren’t paid by GitLab.

So, we see it as, instead of having a tool chain where you have to make the integrations yourself—and that’s not just a few, we identified over 24 integrations you have to make in a standard DevOps tool chain. Instead of making them all yourself with your DevOps tooling team, you work together with 100,000 organizations and 1,800 people to do that.

So, that’s the big secret. It’s open source. We work together. Then there’s some small secrets, and one of them is iteration. Iteration is one of our six values, and it’s something that everyone is super excited about when they join, but they all kind of don’t understand how painful it is, because it’s very, very painful to do the minimal thing. We’re now in a call with Ashish that Ashish will probably not like that we’re gonna probably change the header on our home page today, because we thought of something better. He’s probably gonna say no, but give me a month, I can think of something even better. And I will be like, “That’s great, Ashish. Think of something even better and then change it again.”

Shimel: Yep.

Sijbrandij: It’s very, very painful, and we do that throughout the company, and in product, it’s a very painful thing. My previous call was with Martin, and they’re working on a cloud native chart for GitLab, and we have a thing with uploads and we probably are gonna ship a chart with an NFS server as a part of that. A very clumsy thing, but it unlocks everybody else, and we can keep shipping. And one of our other subvalues is boring solutions, and I love that, because it’s so obvious. You say “boring solution” and people understand what you mean. We don’t go for the shiny toy. Our mission is, everyone can contribute, and people can only contribute if there’s a stable environment to do that, if they understand what you’re doing.

So, when I saw the GitLab code base a year after Dmitri created it, I expected to see a hobby project. Someone super passionate, but doing this outside of work, like, putting some new development paradigms in it and having something that is hard to comprehend, especially since 300 people already contributed in that first year.

And instead, I opened up the code base, and I saw a pristine Ruby on Rails application. Totally idiomatic, like, exactly how it should be, and we kept that. We don’t allow anyone to do anything that isn’t boring, and that enables everyone to contribute. That enables us to make forward progress, and we adopt the best of what’s out there. We embrace Kubernetes, we embrace Prometheus—really great, rock solid open source solutions that we can build for later on, and that’s been a big success.

Shimel: Absolutely. You know, Sid, that was a mouthful in more ways than one, right? So, let’s hit on a couple things. First of all, harnessing the power of open source, right? Right out of The Cathedral and the Bazaar, you know, the book, and what’s gone on is, I mean, the false multiplier there is amazing. Of course, there’s a certain amount of a herding cats element to it, right, in getting everyone moving the same way. But if you can, harnessing that power is just—you know, it’s amazing.

No. 2, you know, you spoke about iterations and sort of feedback loops and constant change, right? This is core to DevOps, right? This is DevOps 101 kinda stuff.

Sijbrandij: It really is. This is exactly what we deliver to customers.

Shimel: Yeah.

Sijbrandij: Organizations adopt GitLab because we can make their DevOps life cycle three times faster, but you still have to work between the tools. They had these handles between the tools, they had these integrations that weren’t transparent, that weren’t seamless.

With GitLab, they can work concurrently. As soon as you push your change, QA is gonna run, security tests run, production is gonna have the first review up out there. There’s not a sequence to it. It is, you paralyze the whole process and you gain tremendous speed and you reduce your time to value, and you allow to get feedback and to improve based on that. That’s the value we bring as a product and of course, we try to practice that ourselves.

Shimel: Yeah. Well, so, but you more than practice it yourself. I think, you know, Sid, I’m a little different. You’re the CEO of this great company, GitLab. I’m an observer, I’m a fly on the wall of many DevOps companies, of many DevOps transformations, and I will tell you, the DevOps tools providers who do it best are those who eat their own dog food, who are practicing DevOps themselves. If you can’t do DevOps internally, don’t try to tell other people how they should do it or, you know, what they should be doing.

It’s not a case of “do as I say, not as I do.” You have to live that, you have to talk the talk, walk the walk in order for you to truly understand it well enough to get other people to buy into it and be successful. So, kudos to GitLab for doing that.

You guys recently announced an acquisition in the securities space. We’re kinda running low on time, but I wanted to just touch on that. Sid, your take on it?

Sijbrandij: Yeah, we acquired a company called Gemnasium, and I think they’ve done the best job of any company of assessing all the different libraries, all the dependencies that are out there and saying which ones are vulnerable, which ones contain a problem. And that is functionality that’s gonna, that’s part of the DevOps life cycle, so we want them to be right in the product.

So, we’re really happy to join their team, and I’m super proud of them for embracing our values, because they joined us, and within three weeks, all the Gemnasium functionality ended up in GitLab, so.

Shimel: That’s cool.

Sijbrandij: We know we hired the right people, they’re amazing, so congrats to Philippe and his team.

Shimel: Yep. Congratulations to them. And look, we see it here, you know, this whole DevSecOps thing, if you will, if you want to call it that, is probably, along with testing, two of the hottest areas within the larger DevOps community.

Ashish, we’re almost out of time. Let me come back to you, though. So, you joined this fantastic organization. We’ve heard from Sid a little bit of a peek into what’s making this engine roar, this rocket lift off. What are you gonna bring to the table? What are we gonna see from you, Ashish?

Kuthiala: I think we need to take this message out to the marketplace, like, you know, a couple of things you talked about when people hear GitLab, they sometimes confuse it with the Git community and other Git offerings like GitHub, for example. So, we really need to tell the world what we are doing, and we are much more than just a repository engine, right? We do a lot more.

And now that, you know, we are out there trying to help other customers with their DevOps challenges, it’s actually a little bit more than what Sid mentioned here; he is being humble. So, not only are we practicing our own DevOps methodology to develop and roll out our application, but we actually use DevOps in every single aspect of running the company, right? Right from the hiring process when I joined to everything that I do in the company adopts a pipeline—you know, you create an issue and you run it through the pipeline and you merge that issue and it goes to production. If something is wrong, you know, it comes back.

Amazingly, everything, between signing for benefits to updating the webpages to running our tracking of issues of what we do, it’s all run through pipelines. And I think I see that as a future. You know, DevOps is not just to be applied to delivering IT value, but you know, it is a methodology that can be applied across running your company for all functions.

So, I think the version of GitLab is much bigger than just helping companies deliver efficient software really fast out there with feedback on the DevOps methodology. It’s almost to pivot and change the way we think about delivering value to our customers, in every aspect of running the company that we do. And I want to be part of that. I think it’s really exciting. I can’t wait to kind of start talking about this to everybody and, you know, seeing how we go down this journey.

Shimel: Great. Sid, we’re over time, but I want to give you the last word, so I’m gonna ask one last question for you. What can we expect to see next from GitLab?

Sijbrandij: We detail a really ambitious vision, and the vision is called Complete DevOps. And we said we’re gonna realize that this year, and we’re executing on that. We’re really proud, we integrated a complete web IDE in GitLab, so VS code running in GitLab. No need to check out this autocode base, you can just edit right there and then.

But it consists of a lot of parts. We’re gonna have real time editing of issue and merge request descriptions. We’re gonna add logging to GitLab. You can already do monitoring, but we’re gonna add something for your logs, we’re gonna add application performance monitoring. Lots of other things that we think are needed to have a complete solution.

So, if you started a startup, the only things you have to do is incorporate it, get a Kubernetes cluster, and install GitLab on it—job solved. Like, you’re up and running, you don’t need any other tools, and the only thing you have to do is, you push your code and already today, GitLab detects what language is it, it builds your code, it tests your code, it tests for all the security issues that might be there, it tests your code quality. It gives you all that. It gives you a review app to work with, kind of a staging app. That already works in GitLab today and we’re expanding on that, and I’m super excited to deliver that to the market this year.

Shimel: DevOps complete. Thank you. Ashish, Sid—thanks so much for being our guests on this episode of DevOps Chat. Continued success with GitLab. We’ll be checking in—actually, I’ll see some of the GitLab folks at IBM Think in a few weeks, and we’ll get an update there, but Sid, you’re always welcome to be a guest here, don’t be a stranger, and congratulations.

Sijbrandij: Thanks so much. Thanks for having us. I enjoyed this. Looking forward to coming back.

Shimel: Alright, Ashish—

Kuthiala: Thank you, Alan, for having us.

Shimel: – good luck, my friend. Be well. This is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat, and we’ll see you soon on another DevOps Chat, everyone.

— Alan Shimel

March 2, 2018
Automation Levels the Playing Field for Continuous Compliance

At this point, I doubt there is any company doing business anywhere that doesn’t fall under at least one compliance framework. One universal truth of compliance—in intent, if not in practice—is that it is a process, not an event. Checking boxes and passing an audit is a requirement of most compliance mandates, but the real value of compliance lies in maintaining that level of visibility and security all the time—which is why continuous compliance is important.

The Need for Continuous Compliance

Hopefully I don’t need to continue to make the case that compliance is an ongoing requirement. Because it is something that needs to be consistently monitored and maintained, it also makes sense to automate the process as much as possible.

In a report titled, “How to Avoid Compliance and Audit Concerns When Using DevOps,” published in November, Gartner stated, “Auditors favor the consistency and traceability of automated systems that have strong logging capabilities and transparent auditable controls.”

A recent survey of more than 1,500 users conducted by Chef found that 74 percent of cross-functional application, infrastructure and security teams do exactly that, though: They assess software for compliance manually prior to production. Once violations and vulnerabilities are discovered, half remediate manually instead of automating the process. Manual processes result in teams’ detecting and remediating security issues in days (31 percent) or weeks (19 percent), instead of hours (18 percent).

“At scale, manual reviews or out-of-band security tools bolted onto the DevOps pipelines won’t be able to keep pace with new velocity of change,” said Derek Weeks, VP and DevOps Advocate at Sonatype. “We saw this first with paper-based open source governance policies in the application security realm and it’s exciting to see similar approaches applied to infrastructure.”

Andrew Storms, VP of Product at New Context, agreed. “Infrastructure automation and configuration management are key requirements for securely storing and transmitting data. … In DevSecOps, bringing security into the development process early and often helps ensure more cost-effective data security.

“Think about this: By 2020 there will be some 20 billion IoT devices connected to the internet,” he continued. “Most organizations can’t even handle automating security and compliance of their existing infrastructure. The growth demand is far outpacing human abilities. Organizations simply cannot afford to rely on the methods of treating our infrastructure as cute and cuddly pets—and spending weeks producing evidence for security audits is not going to happen.”

“Rather than force cumbersome security processes on top of the DevOps pipeline, security and compliance professionals need to adopt a new mindset of integrating controls as code,” Weeks added. Codifying controls initially improves the performance of the checks, but, over time, serves to expand the breadth of security and compliance practices as more controls are coded.”

Speaking a Common Compliance Language

Effective communication is a critical part of the process. “If you were ever in doubt on the importance of testing, then you should ask NASA about how they lost the Mars climate orbiter,” Storms said. “Years of development and likely some millions later, the space probe burned up because two software components weren’t using same units to communicate.”

Chef just released InSpec 2.0, which advances the capabilities of compliance automation. Mike Vizard wrote, “InSpec provides a mechanism to automate compliance management using a set of declarative tools that don’t require anyone on the IT team to possess programming skills.”

The leveling of the playing field by removing the need for programming skills is crucial for DevOps organizations, noted Julia Dunn, Director of Marketing for Chef. “One of the main challenges to DevSecOps (getting developers, security and operations to work together) is communication: not only seeing each other’s point-of-view but having a common language to collaborate on requirements,” she said. “InSpec is a framework that allows for those requirements to be expressed unambiguously in something all three groups can understand. This is in contrast to the previous state, where security throws lengthy scan reports over the wall at operations, or developers toss insecure code at security folks for manual inspection.”

Jon Williams, CTO of niu Solutions and a Chef InSpec user, has seen the benefits of such a technology. “InSpec has helped us unify our compliance, security and DevOps teams and streamlined audits, reducing the thousands of staff hours usually required by as much as 95 percent and eliminating duplication of effort and data throughout the process,” he said. “It has given these teams more control over compliance policies and enabled business units to be more active in maintaining their own environments. Most critically, it allows us to continually monitor for audit compliance, ensuring desired state and eliminating change drift between nodes.”

Regardless of what technology you choose, it is important you have a process or framework in place that enables the various parties involved to speak the same compliance language. It is also crucial to automate as much as possible to provide continuous compliance rather than just passing a compliance audit and assuming everything will stay that way.

— Tony Bradley

February 26, 2018
DevOps Chat: Startup Playbook, Founder to Founder Advice w/ Rajat Bhargava

Two old, good friends of mine published a book yesterday called Startup Playbook. The book is “founder-to-founder advice on how to create and build your startup.” In this DevOps Chat, I sat down with my friend and co-founder Rajat Bhargava. We talked about why he and Will Herman wrote this book, what he hopes others can learn from it and Raj gives us 3 tips on what every first time founder should know.

Between them, Will and Raj have started more than a dozen venture backed companies and have had multiple 8 and even 9 figure exists. If you have ever thought about starting your own company, had a great idea but weren’t sure what to do with it or just thought you could do a better job than the people you work for now, this book could be what you are looking for.

For this week (Feb 19) the book is available on Kindle for just 99 cents! Here is the link for the kindle download.  Also a few times at the end of our conversation I referred to the book as the “Founders Playbook”. I tried to dub in the correct name, the “Startup Playbook” but my feeble interviewing skills are far superior to my sound engineering ability. Apologies.

As usual the streaming media of our chat is immediately below, followed by the transcript of our conversation.

Audio

Transcript

Alan Shimel:   Hey everyone, it’s Alan Shimel, devopsy.kinsta.cloud, DevOps Chat. We’re here with another great DevOps Chat. Today’s chat is a little different for a couple of reasons. First of all, my guest is a very long-time – did I say long-time? – friend of mine, Rajat Bhargava. Raj, welcome to DevOps Chat.

Rajat Bhargava:         Thanks for having me, Alan.

Alan Shimel:               Hey man, thanks. Secondly, our chat today is a little different. Rather than talking nuts and bolts of DevOps and that kind of stuff, we’re gonna talk about Raj’s new book, along with his co-author, another friend of mine, Will Herman, called The Startup Playbook.

Raj, I’ve known about the project for some time, but tell our audience, share with them what is The Startup Playbook. Why did you write it?

Rajat Bhargava:         Well, The Startup Playbook is really our founder-to-founder conversation with other entrepreneurs. We’ve seen so many books out there that are from DCs, they might be from analysts, they might be from other folks out there, but we felt that founders out there needed a book from us, from other founders. Whether we wrote it, Will and I, or somebody else, we just felt like somebody had to talk about the tips, the secrets, the tribal knowledge, the stuff that we get by getting together and talking to other founders. We just felt like that was missing.

We have these conversations with so many other founders on a daily basis because we mentor and advise and help support other founders, we just felt like we needed to write it down. It’s like around the campfire, we have so many of these conversations, we felt like we needed to write it down so that there was a place that other founders could go to to learn quickly.

Alan Shimel:               Just in the way of full disclosure, you know, Raj, you and I have worked together on at least two or three companies, maybe more. But in the way of background, you’ve actually founded, what, about eight companies now, starting when you were still back at university at MIT, correct?

Rajat Bhargava:         Yeah, that’s right. So, it’s probably now close to 10 that I’ve helped start, or started myself. There’s just a lot of mistakes that I’ve made and a lot of challenges that I’ve faced, and I wanted to share those. On the same, Will has probably started five different businesses and he’s got tremendous experience, tremendous knowledge. We’ve both been through so many different things that we wanted to share those so that other people didn’t have to go through the same pain that we went through.

Alan Shimel:               As we used to call it, the idiot tax, right?

Rajat Bhargava:         That’s right.

Alan Shimel:               Our audience – I don’t know how many “entrepreneurs” we have listening in, though I hope there are some – is made up of a lot of technical people. People, Raj, not that different, frankly, than you, right? Who have a great engineering background, live, breathe and die in today’s technology.

I’m sure there’s a big subset of them out there who maybe have a great idea, who see a hole in the market, who see a need in the market, have something that they say can really maybe change the world and make a great company. But they just don’t, they’ve never done it. They don’t know where to start. I know that’s who you are aiming for a lot in this book. Talk to us a little bit about that persona, that kind of person. What’s in the book for them?

Rajat Bhargava:         Well, this book is absolutely targeted directly at them. In general, the book is a founder-to-founder conversation. The founders we’re really trying to target are those first-time founders, the folks that haven’t been through it before. Like you said, they may not know all the steps that they need to go through. They may not even know if founding a business is the right thing for them.

So, we actually start before you start a business in the book. We start about whether this is the right thing for you to do for you, for your family, for you as a person. Is founding a company the right thing for you? We start there. So, it’s from the ground up and we build up from there.

I think our belief is – we’re biased because both Will and I were engineers by educational background – we think some of the greatest businesses are started by engineers, by technical folks. We love when technical folks bring ideas forward, and we think they can change the world. The challenge is that the idea is just not good enough. Ideas are, unfortunately or fortunately, either way you look at it, they’re a dime a dozen. It isn’t the idea that’s so differentiating; it’s all of the other work that you do around the idea that makes it differentiating, that makes the successful business.

That’s a lot of what we talk about in the book is that the idea really just isn’t enough. It’s a seed. It’s a kernel. It’s where you start, but it’s just the beginning. It’s a long, long journey, but a great idea is a wonderful place to start.

Even an okay idea is a great place to start because you can iterate on it and you can improve it. You can make it much better. Then, a lot of the stuff that you do around that idea is what differentiates you and helps make you successful.

So, for your audience, for technical folks who have an idea, we think that’s fantastic. That’s a wonderful, wonderful base to start with, to build a business.

Alan Shimel:               You know, there’s a lot in there, Raj. I want to highlight a few things. First of all, it’s true, whether you have a job or you’re starting your own company, but don’t underestimate that when you go to start, become a founder, that it doesn’t just affect you, right? It affects your family, your loved ones, your significant others and what have you. Because I’ve never met anyone who is successful with a half-hearted attempt to start a company, or to start a business, or to nurture an idea like that, to nurture a business. To me, it’s either you’re all in or you’re out.

Rajat Bhargava:         Absolutely, yeah.

Alan Shimel:               That’s one thing I think people need to think. Let me also hit on one other thing and that is when you speak to people, and you’ve spoken to more than me, but I’ve spoken to my share, what’s the biggest thing holding people back? If I took a poll, Raj, and said, “Hey, who would like to start their own company, be their own boss, and make a lot of money and be successful?” Very few people are gonna keep their hands down; everyone wants to do that.

What stops people from doing that? Well, number one, it’s a little bit of fear of the unknown, having never done it. But number two, the biggest thing I hear from people is, “My god, I don’t have the money to get there. What am I gonna do until my company makes enough money? How do I bridge from having a job with a steady income that keeps the lights on to the time where my startup is enough for me to support myself?”

That’s probably the single most scariest thing for first-time founders. What do you think?

Rajat Bhargava:         You know, I think you’re right. I think there’s absolutely the fear of the unknown and fear of failure which, by the way, 9 out of 10 startups, according to the research, fail, which we actually think is low. We probably think it’s closer to 95 out of 100, maybe even 97 out of 100. Very few companies succeed long-term. The ones that are breakout successes that we hear about in the media are few and far between. It’s so few of the ones that start.

I think the second point is such an important point, which is how do I go start this business when I need money to live on, and there’s no cash coming in at the beginning? Well, that is a very, very hard problem. The good news is there are so many solutions to it, but some of it is a leap of faith, too.

The thing I would start with is there is so much prep work that needs to happen before you launch a business. That is where we spent a tremendous amount of time in the book talking about how do you vet your idea? That doesn’t have to happen only with you quitting your day job, and going and working on it. Some portions of that at some point you may need to do full time, but you can do a tremendous amount of research, of vetting your idea, of building your plans, of figuring out whether this concept that you have can be really, truly built into a business.

We encourage people to spend an inordinate amount of time at the beginning going and doing that. Because if you can build the right foundation at the beginning, you’ve got a shot at making it successful. If you start with a very shaky foundation, those cracks are gonna get exposed very fast and the chances of you succeeding go down dramatically. So, even if you need that job, even if you need that income coming in, there’s still a lot you can do to build out your concept and build out your business, even before you take the plunge.

Alan Shimel:               Fair enough. So, Raj, if we take that as okay, that’s one tip for prospective first-time entrepreneur founders, ’cause we’re running low on time, give me three or four others, if you can. Maybe a top five of what a first-time founder should…really idiot tax saving tips here that they can really rely on.

Rajat Bhargava:         Sure. I’ll give you three. The first one is the one we just talked about, but I’ll expand it.

I think completely vetting your idea before you really go all-in is so critical. That includes things like the value prop, the target customer. How can you build a team, or who is the team? Can you actually build the product or service that you’re proposing?

Can you differentiate it in the market? How are you gonna go get customers? How can you make money? Can you raise money to support yourself? All those things are the art of what we call vetting your idea. The more you can vet the idea from the beginning, the more solid of a foundation you have. That’s tip number one is completely vet your idea.

Tip number two is build a team around you. People think that starting a company could be just a single founder. Especially as an engineer or a technical person you might say hey, I’ve got this great idea. Why do I need to have another co-founder until later?

Well, we encourage you to get other co-founders right out of the gate. At least one, if not two. It’s critical that you have some people who are side-by-side with you as you go through this journey. Find people who have different perspectives, but that you can really work with. It’s one of the most important relationships that you’ll have in the business.

The third thing is find mentors, advisors, board members, people that have done it before that you can learn from. There is nothing like saving yourself time, mistakes, challenges, problems by hearing advice from others. You have to be open to it, but if you’re open to it, you can really accelerate the progress of the business.

Those are three quick tips that I would say are things a first-time founder ought to think about really hard.

Alan Shimel:               Yeah, and those are three good ones, too. I’m sure the book is chock full of more of them.

Raj, let me throw you a little bit of a curveball. In addition to wanting to start businesses because they see needs in the market, I can’t tell you how many engineers and technical folks I speak to that would like to write a book. Again, I don’t know what stops them. Many do cross that chasm, right, and write a book; many don’t.

For people who maybe don’t want to start a business today, but do want to write a book…and most of them are not novels. They’re much like Founders Playbook, non-fiction kind of books. What advice can you give to budding or prospective authors out there?

Rajat Bhargava:         You know, It’s different for everybody, but the thing that I think helped Will and I the most was we just broke it down into a little bit of time every single day. When I initially wrote the first draft of the book, I had a target of 1,000 words a day, which isn’t a lot, as you know, Alan. You can write 1,000 words probably in about 30 minutes, so it’s really not that much time. But if you plug away at that for 90 days, for just one quarter [break in audio]. The typical book is really more like 45,000 words. If you did it for 90 days, you’ve got 1,000 words, and you can throw away half of those words because –

Alan Shimel:               And still have a book.

Rajat Bhargava:         And still have a book. Or you could have two books, right? I think that’s the biggest thing is just don’t try and do it all in one sitting ’cause you can’t. That’s not the way it happens. You need to just chunk it up and do a little bit at a time. In my case, what I did was I just started writing. I didn’t even really have too much of an outline. I just started writing 1,000 words a day.

Then, we took that and we started formulating that into a book. So, we threw out tons of it, we rewrote it a couple of times. There’s just a tremendous amount of editing work. But the editing work turns out to be a lot easier – at least it feels easier; it probably isn’t easier – because you already have something down. It’s the blank sheet of paper that’s really daunting. But if you say, “I have a blank sheet of paper today and I only need to write 1,000 words,” that’s not that bad. You can get there.

Alan Shimel:               Sounds like an agile methodology to authoring a book. Doing it in sprints.

Rajat Bhargava:         Exactly. Yeah, exactly. Do a sprint a day.

Alan Shimel:               Yeah, that sounds cool. A little scrum meeting in the morning.

Well Raj, we’re about out of time here, but for our audience who maybe are interested in taking a look at Founders Playbook, I know you guys are offering sort of an introductory launch as the book goes to launch special. Where can we get some information here?

Rajat Bhargava:         You can go to startup-playbook.com and you can also go to Amazon and just search The Startup Playbook. It is 99 cents for the Kindle version for the first week or so; that’ll come up on Monday the 19th of February. It’ll be 99 cents for a week. We’ve tried to make it really accessible for everybody. We really just want to get the knowledge and the content out into the founders’ hands.

Startup-playbook.com, or look on Amazon, The Startup Playbook.

Alan Shimel:               Raj, beyond the book itself, I know you and Will have plans to try to nurture a community here with that. If people have questions, are there places on the website where maybe they could ask and stuff?

Rajat Bhargava:         Yeah, absolutely. You can reach us on Facebook, on Twitter, on LinkedIn. If you go to the website, there’s links to all of that. You can reach out to us pretty easily. You can find us, and we’d be happy to engage and chat with you.

Alan Shimel:               Sounds great. Hey Raj, I know this was a labor of love, but it was nevertheless a labor, and a long time coming for both you and Will. So, congratulations on the launch of the book, The Founders Playbook. You know what? We’ll keep an eye on it and watch it. I hope some of our listeners out here go check it out. The only thing you have to fear is fear itself. If you’ve got a great idea, the world’s waiting and you can make it happen.

Rajat Bhargava, my friend as well as author of The Founders Playbook, thanks for being this episode’s guest on DevOps Chat.

Rajat Bhargava:         Thanks for having me, Alan.

Alan Shimel:               All righty. This is Alan Shimel. We’ll see you soon on the next DevOps Chat.

— Alan Shimel

February 20, 2018