Tag: devops culture

  • DOES London 2019: Better Value, Sooner, Safer, Happier (BVSSH)

    DOES London 2019: Better Value, Sooner, Safer, Happier (BVSSH)

    One of the key themes for this year’s DevOps Enterprise Summit in London was BV-S,S,H. It stands for Better Value, Sooner, Safer, Happier. It gets to the heart of what DevOps is trying to do: Deliver better value, sooner, safer and it results in happier people and organizations. Gene Kim mentioned this several times on stage at DOES London. I had a chance to dive a little deeper into this during my interview with Jon Smart (Deloitte) and Tom Clark (ITV).

    Both Jon and Tom are DOES veterans and I have had the chance to interview them at prior DOES events. Both of these gentlemen are two of the more thoughtful and enlightened people I have had the pleasure to meet through the years in DevOps. They both have great ideas and notions of what has worked and what hasn’t.

    In our discussion on BVSSH, “C” for cheaper also entered into the discussion. We covered some interesting points about how important cheaper is in the BVSSH discussion. Ultimately, cheaper is part of BVSSH–in my mind anyway. Tom may disagree.

    In any event, have a listen to our discussion on this. Below the interview you can find the presentations from Tom and Jon at this year’s DOES London event.


    Hope you enjoyed these great videos. For more information on how you can be at the next DOES event, check out below.

    Don’t forget! DevOps Enterprise Summit Las Vegas 2019 is happening from October 28-30 at The Cosmopolitan Hotel. Be sure to register here if you haven’t already, and join us for a premier event for the technology leaders of large, complex organizations implementing DevOps principles and practices. You can also preview the event by watching presentations from past DevOps Enterprise Summits.

    — Alan Shimel

  • Successful Transformation: Challenge the Status Quo

    Successful Transformation: Challenge the Status Quo

    If enterprises are going to succeed in their digital transformations, they need to be able to shake-up and challenge the status quo within their organizations. In fact, not being able to challenge the status quo is one of the biggest barriers to successful digital transformations. Yet, challenging the status quo is always a risky move for individuals and small groups within organizations.

    “Many large organizations are intrinsically unable to challenge the status quo and execute a large scale successful digital transformation,” said Mads Hennelund, advisor at consultancy Nextwork. “There are good reasons for this, since established bureaucratic organizations are built in order to handle complex procedures.”

    “Most CIOs, CTOs, and enterprise technology leaders want to challenge the status quo, but doing so can be dangerous because there’s no room for error,” said Laura Stringer, principal at strategic consultancy Ninth Fourth LLC. “IT leaders are under intense pressure to deliver continuity and multiple competing projects on an insufficient budget.”

    But it’s even more than just budget. It’s human nature’s near-ubiquitous aversion to change and inability to endure a number of losses on the road to find big wins. Stringer and other experts we questioned about challenging the status quo all agreed senior business and IT leadership must acknowledge the risks inherent with experimentation, while also providing a comfort level so teams can execute on transformational initiatives.

    Some initiatives will certainly fail and some will succeed. Ideally, like a portfolio of investments, while some investments will fall short, the winners will more than make up for the losses.

    “The organization needs a shift in culture to encourage all employees to become more open to changes in their daily processes and tools–digital transformation is largely about creating a culture of constant learning. Without the pressure to provide perfect continuity in current technologies, IT leaders can become more comfortable trying new things,” said Stringer.

    “This is one of the reasons why it’s common to see large organizations collaborate with smaller companies for projects,” said Hennelund. “In the financial sector we see a flourishing fintech and insurtech market around established banks and insurance companies. Companies successful in challenging their status quo are those that can navigate between these collaborations or even small in-house sub-divisions that develop new digital IT-based projects,” added Hennelund. “Putting into place a quick decision-making process is also critical.”

    This could include making it possible for stakeholders to hold meetings and move forward with their consensus without always having to get board approval.

    Such shifts in behavior require culture change. So, how do organizations and IT leaders get there?

    First, leaderships needs to make the staff feel safe taking risks and, even potentially, failing. “This only happens in an environment where current practices can be freely challenged without repercussions from upper management,” said Nabil Freij, CEO and GlobalVision International, Inc.“This means that upper management needs to be on board with digital transformation.”

    Only then is the right culture, one that can safely challenge the status quo, possible. “The right company culture is extremely important. One that embraces adopting technology, taking calculated risks, thinking outside the box, rocking the boat, challenging status quo, rejecting complacency, empowering employees to lead and overcome challenges…is the essence of enabling digital transformation,” said Freij.

    The ability to challenge the status quo all begins with building the right culture. A culture that encourages fresh thinking and intellectual risk taking. “Thirty-eight percent of CIOs think their digital strategy would fail without an innovative and experimental culture,” said Joe Garber, global head of strategy and solutions at Micro Focus.

    If so, it’s essential for organizations to build and maintain such culture.

    — George V. Hulme

  • JFrog swampUP: An Insight into Insight Partners

    JFrog swampUP: An Insight into Insight Partners

    Another great event we covered on the Digital Anarchist tour this summer was the JFrog swampUp event in San Francisco. Among the many great interviews we did at swampUp, one was with my friend Thomas Krane, vice president at Insight Partners. Insight Partners is one of the leading investors in both DevOps and Cybersecurity growth stage companies, and Thomas heads up those areas for Insight. Despite his youthful appearance, Thomas has a wealth of knowledge (pun intended) about this market and the players in them.

    I first met Thomas at an Insight Ignite event in Iceland about four or five months ago. Being that we are both so keenly focused on similar markets, it was natural that we sat down to compare notes and learn from each other about new trends, new companies, shop talk.

    JFrog is a portfolio company of Insight Partners and so Thomas came to the event. I thought it would be a great idea to sit down with him and share with you some insight on Insight Partners.

    Understanding the process for how a company with over $20 billion in assets under management, sources investments, keeps abreast of market trends and new companies is beyond interesting. It literally takes a small army to track over 10,000 companies in the space. Thomas and team do a masterful job at it, but it isn’t easy.

    Also for those of you out there who dream of one day getting into the VC business, Thomas gives a little background on how he got into it as an intern in school still. It is a great story of hard work paying off.

    Have a listen for yourself.

    — Alan Shimel

  • Why DevOps Implementation is Often Unsuccessful – and How to Fix It

    Why DevOps Implementation is Often Unsuccessful – and How to Fix It

    Much like “blockchain” and “big data,” the term “DevOps” is another buzzword currently being thrown around the IT departments of large organizations.

    Many have identified the need for faster software development life cycles; a more precise process closely aligned with business objectives, allowing for clearer workflow and collaboration between the development and operations teams. DevOps is essentially agile, all grown up and ready to take on the constantly innovating and rapidly deploying needs of the modern business.

    For security professionals, it’s a fantastic initiative: We can inject security into the process far earlier, reducing the cost of fixing bugs and avoiding potential catastrophe down the track.

    The problem is, few companies are truly successful in their DevOps implementation. Without the right support, nurturing and understanding across the business, it can quickly become a white elephant, you know, one of those “don’t mention the war” projects.

    So, what’s the problem? There are a few ways to approach DevOps that I believe will make for much smoother sailing. An effective program goes beyond a few fancy new tools, titles and team meetings. It’s not always going to be easy but taking the time to fix a broken strategy (or implement it the right way from start) is going to be far less painful in the long run. Ultimately, it’s going to result in higher quality and more secure software.

    Let’s break it down.

    Let Go of the Agile Apron Strings

    There is somewhat of a misconception that an organization must choose between agile or DevOps, setting down one path or the other, never to look back.

    The thing is, the development process works best when both are being considered and implemented as one. DevOps is not a reinvention of agile development; rather, it is an extension of it. The wheels tend to fall off when there is an expectation the process will be exactly agile, or completely different from agile.

    Agile supports the principle of cross-functional teams, bringing designers, testers and developers together from the beginning and committing to open communication lines throughout a project. Its aim is to stop siloed delivery and reduce double-handling, both of which are benefits of the DevOps process as well. However, DevOps goes a step further, introducing systems, security and operations into the mix to offer a robust, end-to-end skillset that had the ultimate goal of full, functional software delivery to the customer.

    During the inevitable pain-points of moving to a more DevOps-centric process, the risk of siloed development can crop up again. You can often have the original agile team working together, with the security and operations additions still finding their way in the machine. No one is quite sure how to include them, what they should be doing and their overall objectives.

    DevOps does not work without clearly defined objectives, cross-functional onboarding and direct communication with all parties. There will be an adjustment period requiring careful change management but getting everyone on the same page with the enhancements DevOps functionality will bring is half the battle.

    Increasingly, DevOps is placing emphasis on security best practice as part of the process as well, demystifying that step and bridging the gap between the security team and everyone else. As I have said before, we still have a long way to go in empowering developers to code securely from the start, but the successful implementation of DevOps methodologies is an excellent foundation on which security skills can be built within the development team.

    Automation Isn’t Everything (and It’s Not the Most Secure)

    Another feature of DevOps methodology is, to a certain extent, the automation of the software development process. Continuous integration and continuous delivery (CI/CD) principles are the cornerstones of this concept, and as you can likely guess, very reliant on tools.

    Tools are awesome. They can bring unprecedented speed to the software delivery process, managing the code repository, testing, maintenance and storage elements with relatively seamless ease.

    However, while robots might take all our jobs and imprison us someday, they are definitely not there yet. Heavy reliance on tools and automation leaves a window wide open for errors. Scans and tests may not pick up everything, code may go unchecked and that presents enormous quality—not to mention security—issues down the track. An attacker only needs one back door to exploit to steal data, and forgoing the human element in quality and security control can have disastrous consequences.

    The happy medium is to ensure you have a balance of people and tools. Tools should serve as the assistants to a team you trust to deliver on project goals. You should:

    • Allocate enough time for people to become familiar with the chosen DevOps toolchain.
    • Focus on effective collaboration (and how the tools can support that).
    • Address any gaps in the process, whether they are skill/knowledge or tool-based.

    In short, don’t just tool up and hope for the best.

    DevOps Isn’t a Buzzword, It’s a Culture – Are you Growing Yours?

    Change management is tough at the best of times. Fear of the unknown can stop even the most brilliant team members from growing their skills and expanding their horizons.

    You see, merely saying “let’s do DevOps” and making the operations team move desks isn’t going to magically implement a successful process. Many will be confused, and long-serving members of the team will be left feeling disgruntled. Communication of expectations is crucial, as is walking the walk. DevOps represents a cultural movement just as much as a development methodology, and a team should live and breathe a cross-functional, collaborative mindset.

    What does a great DevOps culture look like?

    • Individuals are empowered to lend their expertise to a process, not just leaders.
    • Open, honest and respectful communication between teams.
    • Each person takes responsibility for the overall objective of building quality and security into the development process.
    • Everyone is on the same page with the definition of DevOps in the business, the roadmap and how/what/why of each person’s role.

    For years I have emphasized the importance of building positive security cultures in development teams, and DevOps is no different.

    The right tools, knowledge and support are imperative to achieving security best practice, seeing a downturn in discovered vulnerabilities and opening the team’s eyes to the importance of protecting our data. With DevOps, you must lay the cultural groundwork for positive change: Ensure everyone understands their role, value and expectations, the overall project goals and steps in the process.

    Have you mastered that? Great. Now, let’s shift the needle, dial up the security aspect and make DevSecOps the ultimate plan for software excellence.

    — Pieter Danhieux

  • A Culture-Driven Approach to DevOps Transformation

    A Culture-Driven Approach to DevOps Transformation

    One of the most challenging aspects of a DevOps transformation isn’t automating and overhauling technology. The biggest challenge of DevOps is changing an organization’s culture and purpose. You can’t “buy a DevOps.” DevOps demands the involvement of people, process and tools working together.

    Unfortunately, I’ve seen too many companies get carried away with the latest shiny object and neglect the people aspect. So, the end results they were expecting do not come to fruition. Research from Google Cloud and Harvard Business Review supports the importance of a people-first DevOps strategy. This research confirms DevOps transformation projects are worthless without addressing the people aspect.

    Of course, such large-scale transitions are difficult. People have to put their reputations on the line to sell the transformation. Employees may become stressed or resist the cultural changes that come with a DevOps transformation. Therefore, communication throughout the entire transformation must be your primary goal. Communication includes measuring the effectiveness of the transformation vision and goals and sharing that information with your team. Keeping them informed ensures they understand the critical role they play in this vision, as well as the value of their work. These measurements need to also show how participation in change translates to value for the business.

    Here are some best practices for prioritizing people and process when working through your DevOps transformation.

    Communicate Every Step of the Way

    It’s important to establish a level of empathy for your employees and understand exactly how changes will affect them. Employees’ professional identities develop over many years, and you can’t expect them to change overnight. Here are some questions your employees are wondering about:

    • What happens to my job when we have to start adhering to this new process?
    • Will I lose my job when all this automation is implemented?
    • How am I going to learn the skills to be effective and contribute to this new way of working?

    Expect their questions and listen for more areas of concern. Be proactive about sharing both the questions and the answers with everyone.

    It’s critical that you keep an open channel of communication with your employees to help them through this change. Don’t view this as an add-on exercise–it should be the cornerstone. Focus on communication, and devote time to your staff, so they are completely integrated into the new DevOps process.

    Your communication strategy needs to include all the teams involved with application delivery. Hold regular meetings across all departments, not only development and operations teams. Think about how the DevOps transformation impacts departments such as marketing, human resources and finance. What challenges have they run into? Have there been any negative impacts thus far? Listening and addressing each issue in real time will ensure the transformation is moving in the right direction.

    Measure What Matters

    When it comes to measuring your success, don’t worry about what other companies may be doing. The metrics that matter are the ones that support your ultimate business goal, which in this case is a better software delivery process.

    Identifying metrics for your business demands you understand how your company’s process drives behavior. Ask questions such as: What corners were cut to get from development to production on time? Did meeting this deadline impact the timelines and performance of other teams and the quality of other applications?

    Meaningful metrics allow you better insight into your processes in the real world. And meaningful metrics help determine whether your pipeline is moving in the right direction to deliver high-quality, high-value software.

    Remember those regular meetings I mentioned earlier? These are also a great time to focus on metrics so employees understand how their work impacts the business. It’s also an opportunity to hear what’s happening on the ground in the delivery pipeline. This real-world information can determine progress, as well as test if the right metrics are being tracked.

    Conclusion

    A DevOps transformation requires changes to staffing, organizational structure, performance and culture. As a result, the success of your transformation involves moving the entire organization forward—building a strong culture ensures all people at all levels are invested in it. Measuring and communicating results must be the standard for every release you do.

    DevOps can fundamentally change any organization for the good. By continually communicating a clear vision of the goals and expectations of your transformation, people will feel confident they are on a winning track.

    — Tj Randall

  • Is DevOps in the Enterprise Real?

    Is DevOps in the Enterprise Real?

    Is DevOps in the enterprise real? The short answer is yes, but you may assume it’s only relevant to the world’s leading cloud companies because they’re the ones that make the headlines. DevOps offers the promise of agility, quality and ultimately better-performing software. While DevOps processes can increase agility, and agile approaches are a great help in improving responsiveness to change, the overall process still needs a clear objective, measurable KPIs and a finite scope.

    In other words, unlocking the promise of an agile (product) organization requires a few complementary approaches. If those are ignored or applied incorrectly, DevOps agility can become an impediment to adaptability and agility for your enterprise.

    Yet, I’ve read so many blogs about how the cloud and DevOps processes solve problems. It’s true they can, but the nuance is that, while a few teams can coordinate change amongst themselves, when you attempt to deploy a DevOps practice at scale, challenges are quickly apparent. For example, if I’m working for a startup that has fewer than 50 developers and very few layers of management between the CTO and her team, the management and communication lines are likely short enough that strategy and direction can be conveyed directly to the teams. However, for larger organizations—where there are many often geographically distributed teams with silos of responsibility and layers of management—far more coordination and communication are required.

    In these environments, it is more likely the business will achieve agile teams but not an agile culture. This is because it’s too simple and, therefore, commonplace for these environments to execute in silos not aware of changes to other silos and where environmental constraints and dependencies are not considered throughout the development process.

    The best solution to these challenges is to focus on a cascading framework of objectives and goals. Every company has its mission-critical goals—some call them strategic imperatives, others call them (or include in them) board-level mandates—and those goals should cascade into a more refined product, program and team goals as you traverse the management tiers. This ensures the business leaders can set a strategic direction that will be measured in a certain way, and every subsequent layer below them understands how their initiatives align with supporting that direction.

    The first critical element for building a successful, sustainable DevOps culture is understanding your goals and how you’ll define and measure success.

    The next element is to establish which decisions each level of management can make autonomously. For example, risk tolerance is a strategic decision, architecture and security posture are typically defined for a product, platform-level technology decisions can be delegated to program teams and project teams can then focus on making the more granular technology decisions that will differentiate their product, service or feature.

    Finally, communication is key. This sounds trite, but communicating this cascading decisioning framework, exposing the decisions each group makes that could impact the particulars of an environment and then discussing requirements and challenges of architecture and software choices can ensure that each team, at each level, can remain agile and adapt to change effectively.

    The question is: Do you have the management rigor to dig into these challenges and own them? The answer likely lies in how important the pursuit of agility is to you and your business.

    — Ari Weil

  • Why Did DevOps Become So Popular? 3 Theories

    Why Did DevOps Become So Popular? 3 Theories

    DevOps has now been a thing for a solid decade. As we look back at the history of DevOps, it’s worth asking: Where did DevOps come from, and why did it take off when it did?

    In honor of the 10-year anniversary of DevOps, I’d like to explore these questions.

    A Brief History of DevOps

    The very basic history of DevOps goes like this: First, there was agile, an idea exemplified in the Agile Manifesto that gained prominence among software developers in the early 2000s.

    Then, in 2008, Patrick Debois, a developer from Belgium, conceived of DevOps as a way to improve upon the agile concept by encouraging developers to work more closely with ITOps teams. His ideas began spreading in 2009. By the early 2010s, they had gained a sizable following and the rest is history.

    That, again, is a really basic history of DevOps. For more detail, I recommend this DevOps history post by Steve Mezak.

    Why DevOps? Why Now?

    The narrative of how DevOps originated is one thing. Explaining why DevOps became so popular in a relatively short span of time is another.

    As I see it, there are three possible theories to explain the rise of DevOps over the past decade. The first is to argue that Debois simply happened to have some very good ideas, and he promoted them well. You could think of this as the great man theory of DevOps’ origins. This seems to me, however, to be an unlikely explanation. It’s very rare for highly influential ideas to be born from just a single mind, or to spread through the singular efforts of one person.

    The second possible explanation for why DevOps became popular is it is simply an evolved form of agile. This is like arguing that World War II was simply a continuation of sorts of World War I, and therefore the origins of World War II are ultimately the same as those of World War I. From this viewpoint, the history of DevOps is really the history of agile, and so DevOps itself doesn’t have a unique history at all. I’d find this argument compelling if I believed DevOps is really just agile by another name, but I don’t. DevOps is broader, and has a much stronger implementational and practical element.

    The third theory—and the one I find most persuasive—is DevOps was born out of a particular moment in the history of computing and IT. That moment, which started in the mid-2000s, was marked by several key features that helped give rise to DevOps, including:

    • The widespread adoption, starting circa 2007, of cloud computing.
    • The success of the open source software movement around 2010 in making open source the go-to licensing strategy for many popular software projects and in making collaboration around code easier.
    • The rise beginning around 2010 of microservices and containers, which made applications much more complex to design, deploy and manage.
    • The explosive popularity of mobile computing starting with the launch of the iPhone in 2007. The mobile revolution meant organizations increasingly had to deliver software for multiple target environments (PCs, Android phones and iOS, for example) at the same time, necessitating branched delivery pipelines.
    • The demand for ever-increasing speed in software delivery as a way to gain an edge in software markets which, by the late 2000s, had grown more competitive than ever.

    When you put these changes together, you end up with a need to manage much more complex, fast-moving software delivery pipelines. Powered by cloud infrastructure and microservices architectures, the software market starting around 2010 required more responsive, better coordinated management by IT teams. DevOps provided an answer by increasing efficiency, decreasing response times and making software delivery faster.

    I don’t think DevOps would have taken off if the idea had emerged in the 1990s, when there was much less demand for fast software delivery, most applications ran locally and codebases were relatively simple.

    Nor am I sure DevOps would prove as popular if it were first introduced today. At present, we have a litany of management tools (such as Ansible and Kubernetes, to name a couple of examples) that didn’t exist 10 years ago. Those tools make it easier to handle all of the complexity of modern software environments even if you don’t have a management strategy rooted in DevOps culture.

    To put it simply, DevOps resulted from the combination of several specific developments in the world of IT between the mid- and late-2000s. Debois may certainly deserve credit for helping to spread the idea, but it would not have spread so quickly if it had not emerged at that particular time.

    — Chris Tozzi

  • JFrog swampUP: DevOps Culture Is a Powerful Force

    JFrog swampUP: DevOps Culture Is a Powerful Force

    The notion that culture is such an important part of DevOps and high-performing IT teams gets plenty of lip service, but not every organization really buys into it. In my years covering the DevOps space, I can count only a handful of companies that truly represent the epitome of “DevOps culture.” One of these companies is JFrog.

    Every time I have the chance to interact with “the Frogs” and their community, I am reminded of what a powerful force culture can be in forging success. At the recent swampUP user conference in San Francisco, the JFrog secret sauce was again on display. From the little things, such as designing and decorating the conference themselves, to the bigger things in terms of the theme of the sessions and activities, swampUP was a great and learning time for all. Our Digital Anarchist team was on hand and we did a bunch of videos that you can watch up on DigitalAnarchist.io. The videos are with speakers at the conference, attendees, JFrog employees and partners.

    One of my favorite videos from swampUP was the one I have embedded here. It is the three co-founders of JFrog—Yoav Landman, Fred Simon and Shlomi Ben Haim and I discussing business and what makes JFrog’s culture so special. Have a listen and maybe get some insight into making the culture of your own organization better.

    Also, if you are in Israel Sept. 24, check out Yalla DevOps, a first-time conference JFrog and others are producing that looks like it will be a great event. The Digital Anarchist team will be there covering with video (even broadcasting live), along with John Willis as a keynote speaker; Jayne Groll, my co-founder at DevOps Institute; and others.

    In the meantime, enjoy the video:

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel for devopsy.kinsta.cloud on Digital Anarchist, and we’re here in San Francisco at JFrog swampUP 2019. It’s been a great conference, and I’m really, really lucky and happy to be joined—I feel like I’m at a Beatles reunion, for some reason. I’ve got Ringo, Paul, John—

    Shlomi Ben Haim: Who’s John Lennon? I’m afraid. [Laughter]

    Shimel: – done. Anyway, but no, we’re not at a Beatles reunion, but we do have the three JFrog co-founders here with me. I’m gonna let them introduce themselves. We’re gonna go to the far right to Fred. Fred, go ahead.

    Fred Simon: Hi, I’m Fred Simon, co-founder and Chief Data Scientist today at JFrog and I’m really happy to be here. Thank you.

    Shimel: Thanks, Fred.

    Yoav Landman: Yoav Landman, CTO and co-founder of JFrog.

    Ben Haim: I’m Shlomi Ben Haim, CEO and co-founder of JFrog.

    Shimel: Three co-founders on one panel—there you go. So, guys, first of all, congratulations on another great event.

    Simon: Thank you.

    Shimel: You know, you know this, but you guys don’t know this—my wife wants to come work with you.

    Simon: [Laughter]

    Shimel: Because she loves the company and the culture and the buzz that she gets when she’s around the Frogs that, you know, when she grows up, she wants to come work at JFrog.

    But all kidding aside, it’s a tremendous—you can’t come to a JFrog event, whether it be swampUP or SwamPower or Meetup or whatever without kinda feeling the love, right? Feeling that culture. And it’s an interesting dynamic. Take it from me—I go to a lot of conferences, I deal with a lot of companies. They don’t all have that. They don’t have that culture.

    So, I wanted to talk a little bit about—look, 2009, you started Artifactory, right? What was the idea on the culture, here? How do you instill that culture—not in the community, right now. Let’s talk about the company, because every high performing team ranked culture as important. How do you instill that pride to be a Frog, we’re all in this together, we’re making the world a better place? Who wants to answer?

    Simon: You want to start? You started this mess! [Laughter]

    Yoav Landman: So, yeah, Artifactory started before JFrog. So, Artifactory was there to solve a real pain, and we were all developers, and it’s our second—except for Shlomi—it’s our second venture.

    So, I guess this idea of solving pains, being very connected to the community, to customers, speaking a lot with customers, getting feedback from every engineer and every employee in JFrog that comes and says that they think that something should work differently or that we should develop something that may contribute to more success of our product is something that is instilled into the culture of JFrog.

    Shimel: Excellent.

    Simon: Yeah, we got lucky that everybody else who is working at JFrog is working for someone like him. So, that’s scratching our own itch. So, at the end of the day, you are a developer at JFrog and you hear about a customer having an issue, you feel it, because this is your job. You’re writing code, you’re a developer, and you know that what you are doing is impacting people. And so, this strong care about the customer and the strong feedback of the culture was here right from the beginning.

    And then Shlomi one day decided, “Oh, that’s too big, too full of a culture. I’m gonna try to write it down.” [Laughter]

    Shimel: [Laughter] And Shlomi, with all due respect, you like to deflect and you let him talk, but you’re the CEO. At some point, the buck stops here, right? You know, it’s important to you, but how do you build this culture? How do you get this loyalty, this feeling of buy-in from people?

    Ben Haim: That’s, you know, I’m listening to the question and I’m  getting excited like it’s my first day at JFrog. I think culture matters. Everybody knows that, everybody said that. But it’s hard to practice. It’s hard to maintain it for 10 years. And this—this goes back 18 years. I think I’m with these guys before I got married, and what you see in JFrog is that when you have the right culture, it’s viral. But it’s not just an internal move, it’s also reflecting outside of the company.

    And you spoke about Artifactory and how it started, and when we started, the only thing that we had was the technology that we believed in and ourselves. And it’s very hard to start a company when nobody understands what you do on the technical level, nobody understands what’s the pain. There is no budget line for it. So, the only thing that you can fight with is your team.

    Shimel: Right.

    Ben Haim: And just yesterday, as we set up this amazing conference here, I saw more than 70 JFrog employees. You know that we do our conferences ourselves.

    Shimel: Right.

    Ben Haim: No producers, it’s just us. Our team built it for the community. And I saw them here walking, and it doesn’t matter whether it’s building Artifactory or Xray or JFrog Pipelines or JFrog Distribution or swampUP—same culture, same values, comes over and over again as our one very big advantage.

    Shimel: Absolutely. But now—so, that in and of itself is fantastic, right? But now, there’s a second key ingredient to the success. How do we take that culture that we built at JFrog and let the community, infect the community with it, right, to use a security term? How do we transform the community with that same—not transform, infuse that community with that same culture, with that same passion?

    Because that’s something that always, again, it screams, right? It’s easy to see. And building that kinda community is not easy, because at the end of the day, today’s software world with open source and everything else is community, right? It’s all about—so how, is that something that’s done on purpose? If so, how? What do we do?

    Landman: I can try and start.

    Shimel: Go ahead, Yoav.

    Landman: So, part of being driven by input is also being very direct. And it all comes down to people—at the end of the day, it’s all people. So, the way that we interact with the community, the way that we interact with customers is not very much different than the way we interact internally in JFrog.

    So, by bonding with people, by investing in clear and open discussions with no fluff, I think that drives results, at the end of the day.

    Shimel: Fred?

    Simon: First of all, I don’t think it’s intentional. I mean, it’s just the way we are and the way—and it’s pure and it’s just true, okay? We truly care about the suffering of our customer, and the customer feels it. So, once he feels it and then he’s part of it—and sometimes, it’s a little bit disturbing for the customer, because the customer feels like he’s gonna get more help and better integration with the JFrog community and with JFrog than with his peers inside the company, because of the [Laughter]—

    Shimel: Yeah, exactly.

    Simon:  – some cultural clash between the company and JFrog. And so, by, you know, not saying, “Okay, whenever a customer is telling you something, just be compassionate”—we never told our employees, “Please be compassionate about the customer.” This is just, this is who we are, and this is what the—and they see, and the customer feels it, and he sees the effort we put to make sure that… And it’s like here, the communication, also. The effort of communication, the effort of knowledge, knowledge transfer. We are not shy on transferring what we know, what we need, what we did. It’s just—yeah, I think truth and natural truth is a [Cross talk].

    Shimel: So, the word that comes to my mind is genuine, right? You can’t fake this. It has to be genuine. And if it’s not genuine, people see through it and it smells, right? So, I think that’s a key ingredient of that, for sure.

    And the transfer, too—I mean, I’ve done, I don’t know, maybe 10 interviews, 12 interviews, maybe more today, to a lot of customers. And that knowledge transfer and sharing in this kinda—it’s huge to them.

    So, now—so, we’ve got the culture to the community. Now, we’re gonna talk, Yoav, you said Artifactory existed before there was a JFrog, right? It’s 10 years, right? In technology terms, that’s like dog years, it’s 90 years, you know? It’s almost 100 years old already.

    Landman: Frog’s years. [Laughter]

    Shimel: Frog years. How do you—so, obviously, the Artifactory today is not Artifactory, what it was.

    Landman: For sure.

    Shimel: JFrog today is not what JFrog was. We mentioned something things—JFrog Pipelines, there was the Shippable acquisition, Xray came out about two years ago now, right? Two, three years ago—Xray. JFrog today—let’s talk about the technology, the tools, the solutions. What are you most—you’re CTO, Yoav. What are you most proud of with that?

    Landman: Artifactory was the centerpiece and it still is. It’s the place where you put—we call it the golden bits. It’s what you’re going to, at the end of the day, put in production, right? But the world has changed dramatically since Artifactory was written. It was just a very basic Maven remote proxy. And then other features came about, but the whole DevOps and the whole pipeline automation process that we’re seeing today within companies, it didn’t exist back then to the same level of automation.

    So, bringing in security into the pipeline is an integral part, with Shippable, making sure—we can maybe talk about this later—making sure that we can drive the pipeline, adding functionality to give you insights into the pipeline. These are all things that came along and are going to be injected into the pipeline from JFrog, from other companies, but this is the natural evolution. Artifactory is still the base of what you’re going to shift, but all the services around it is what makes JFrog a lot bigger and why it’s very different than what we started.

    Shimel: Fred, I wanna come to you in a second, but I have a follow up question for Yoav. So, Yoav, I think another great example is—so, in the last year, you announced you’re gonna start a repository for Go, yeah? And so, that’s an example of, you see what the community is doing. I spoke yesterday to a Microsoft fellow here who’s, like, their advocate for the Go community—so happy to be here because JFrog’s supporting him with that.

    Where does that come from? Like, where—the idea of saying, “Hey, we should do something for Go?”

    Landman: So, it comes from, I think, two angles. The first is purely technical, just being able to be there first. The other one is, I think, a little bit cultural, just being able to instill innovation into the company, even before the market adoption happens. And it kind of goes together. Both goals, they serve one another. So, we did the same, by the way, with Docker. With Docker, we had support for the Docker beta versions, even before Docker was a thing.

    And the same thing we wanted to do with Go, even when the standards were not that stable yet and we had to rewrite our implementation once the standards have stabilized. But yeah, this is the source of this motivation.

    Shimel: Fred, I wanna go to Liquid Software with you, right? So, it’s a book, we can probably have someone throw us a copy for a prop, if we can get Brian maybe get us a Liquid Software book over here, it’s right by Netta.

    But you’re one of the co-authors, Yoav, Baruch is one. So, that’s another concept, right? This whole concept of liquid software and what it is. Talk to us about that. What do we—where does that come from? How does that fit?

    Simon: Yeah, so the—by the way, where it goes to Go and all these kind of communities and things like that? The origin of manipulating software and trying to put software in production into an environment, we always try to manipulate it as boxes. A box where we put a bunch of software and we try to run it. And with the advent of releasing multiple ________ multiple versions and making all those services micro-micro-microservices—basically, the flow of those packages got higher and higher and the size of the packages got smaller and smaller.

    And so, instead of thinking about it in terms of ship management and supply chain management of shipping packages, it didn’t make sense any more. It was really, really a big burden on the tagging.

    And so, when you want to put a piece of software in production, you have the final run time, which is the software in the hands of your end user, the one that really, really wants to use it. And deploying software is actually easy. You just created a new piece of software, you just run it for the first time, and it’s quite easy, and then you run. What’s hard is to update it, okay? Deploying is easy, updating is hard. And the only way to update it is to get the new version. And if you keep thinking about it in terms of blocks, you’re stuck. You need to think about it in terms of pipes and liquid and this is the liquid software. Is that, as soon as you create a run time that can receive software, you need to think about all the pipes that you need to plug to get the liquid to it and to update it continuously.

    And it changed all the way to the developer. This is—it starts from the pressure from the end users from, like you said, your wife, your daughter or whatever that wants to get the latest software all the time without any, and it put the pressure all the way to the developer. And what’s funny in our environment is that it’s hard for a developer to do it correctly, and a lot of times they said, because they are used to it, when they interact with technology, actually, the developers are a lot more, first, reluctant to update software. If you see all the developers and their phones, iOS and Android, they have the most, the oldest version, the one that doesn’t update. [Laughter] And they want to control [Cross talk].

    Shimel: It’s the mechanic’s car.

    Simon: Yes, exactly. [Laughter]

    Shimel: Never drive the mechanic’s car.

    Simon: And so, for them, it’s not that complicated to do a complicated update. So, it really comes from the pressure from the market, and life is ________ is a really good, it’s life pushing it and so liquid software is gonna happen whenever it’s gonna happen.

    But the change that we need to push is to put the tools and the mechanism and the practices into the hands of the developer. Because it’s not that hard. It’s hard, it’s some work and stuff, but it’s not as impossible as the community of developers think.

    So, it’s a book, I highly recommend it.

    Shimel: Here’s the book. We’ve got the book, thanks to the folks offstage.

    Simon: But it kind of tried to remove this fear from the developer community of writing liquid software. It’s possible.

    Ben Haim: And, you know, Alan, I think that the experience of being in a very successful company for over eight years and not being able to explain what is it that we are doing, why it’s more than just managing your binaries, why it’s more than just providing you with a better repository. And when Fred came up with this phrase, liquid software, it was one presentation that everybody in JFrog understood and immediately aligned to it. Because this is actually what we believe in. And when you go and raise your Series D and you say—

    Shimel: Which was this year.

    Ben Haim: – this last year, last October, seven months ago. And when we said—nine months ago.

    Shimel: Yeah. [Laughter]

    Ben Haim: When we said, “We are the liquid software company,” we had all kinds of eyebrows moving, and people are asking us more and more about that, because they start to understand that this is beyond just the vision of JFrog. This is where the world is going. We are just one of the enablers of the liquid software world.

    Shimel: Absolutely. So, first of all, I still can’t explain to my family what I do for a living, but that’s another story.

    Ben Haim: [Laughter] The story of my life.

    Shimel: Yeah. But, you know, in some ways, this is also the story of JFrog, because 9 years ago, 10 years ago, Artifactory, I would’ve told you, “Liquid software? What is it? What do you”—stop.

    Ben Haim: Yeah. Stop with the drugs.

    Shimel: Right. But yet, the kernel of what is liquid software according to you was there in Artifactory 10, 11 years ago. Yeah.

    Landman: The essence is.

    Shimel: Yeah. and so, it’s—you know, I learned once, what we do in technology is, 99 percent of the time evolutionary, not revolutionary. And so, this is the revolution of it.

    So, I’d like to, now, if we can—and Liquid Software is available, you can get it. The book’s on Amazon. I think it’s on—

    Simon: Audible. It’s Audible, also.

    Shimel: Yep. We had it on devopsy.kinsta.cloud on a link, too, at one time. We probably still do, obviously.

    But I wanna now turn a little bit, you mentioned D round was a couple dollars, 165,000,000—that’s not even shekels, dollars.

    Ben Haim: [Laughter] It sounds better in shekels, by the way.

    Shimel: Yeah. It’s like the speed of light. But you know what, when you raised—Yoav and I were talking earlier—you raise that kind of money, with a lot of money comes a lot of responsibility, a lot of expectations. Where does JFrog go from here, right, and how do you chart that course, right? As a CEO, CTO, developer advocate, technology—how do we, where do you, where do you go? How do you know where to go, right? You’ve got tremendous resources now at your disposal, probably more than you might have dreamed you’d have to do.

    Where do we go and how do chart that course?

    Ben Haim:  So, I’ll try to answer that from a high level and then, of course, Fred and Yoav can take it to the technology solution. I think that JFrog has done something really big. And when you see what happened in the world, it’s beyond the developer. It’s beyond the people who are actually using our solution. It’s the destination that was changed. And what people expect to have is a fast and fluid software update. And if JFrog, with 5,000 customers today and growing fast, can be the company that powers this need, then I think we have a very big story.

    So, when we raised our money—you know, when you raise such an amount with such an evaluation, you also understand that the dream about M&A and exit is kind of pushed away and the list of acquired got changed to maybe three or four companies.

    Shimel: Very small—a handful.

    Ben Haim: So, you have to go and ask your wife about it, because this is 10 years, together 30 years of investment that our family was part of this journey. And I asked Donna, my wife, and I said, “Donna, you understand that there will be no exit soon. We have to go all the way—all the way towards it.” And the answer that I got is that, “If this is really what you say it is, if it’s really changing the world, if it’s really about electricity and water and aircraft and cars and everything you do, I’m so excited about it, and I’m not even a technologist, then you guys should go after it.”

    So, I think we have made the right choice, and you’re right, there is a lot of responsibility here. It’s a responsibility not just to our VCs, but also to our employees that trust us and follow us, and also to our customers—

    Shimel: And the community.

    Ben Haim: – that comes and uses it and over and over again, we are growing at 150 new logos per month—new logos per month. These are people that adopt this solution and say, “This is what we are going to do in the next 10 to 20 years. We are making software liquid.”

    Landman: So, JFrog for a long time is not just the sum of the founders, it’s much, much bigger than that, and we have wonderful people in the company that leaped forward with JFrog and take the company forward, basically, for us and for the other investors.

    One thing that you have to understand is that, today, JFrog is taking the responsibility of serving huge organizations and our end customers are also sharing this responsibility of serving the automation for huge organizations, and the automation patterns that we are seeing, they are not constant. They are changing and they keep evolving over time.

    So, this is kind of great, an ever growing challenge for us to develop a new set of tools, a new set of solutions, new pains to cure. To tell you that we exactly know what the next pains are going to be—we don’t. If we would, it would probably be too boring to continue going, like Shlomi said. But this is basically what drives us and keeps us committed to this responsibility.

    Simon: Yeah, still a ton of work to do. I mean, the liquid software vision, there’s still a lot, a lot, a lot to do. And like Yoav said, the responsibility that we have as being a critical piece of keeping those pipes, making sure they don’t leak, making sure nobody’s injecting stuff into it. And making it happen and making the water system trusted and the software delivery trusted is a huge amount of work, responsibility, and systems that we have to create on the way, we have to build, and we have to scale to worldwide—really, worldwide impact and environment.

    So, you can say that 160 is a lot of money, and when I see the amount of things that need to be done, maybe not. [Laughter]

    Shimel: Yeah. Well, there’s always more out there. Guys, we’re way over time, but I wanted to end it with this. I sold my first company in 1997, and I sold it to, well, a guy named Brad Feld who’s a pretty well-known venture capitalist himself. But his mentor was an older Jewish man, Len Fassler—a little older, he was like my grandpa. I couldn’t negotiate against him.

    Ben Haim: [Laughter] No, it’s impossible.

    Shimel: It was like negotiating with your grandpa. But Len had good—he did several billion dollar companies, rollups and good stuff. And I then worked for him and we did 30 acquisitions in 36 months, and we wound up taking the company public in the dot cot days.

    And one of the things he always said to every founding group, whether we bought the company or not, was, “Any time you can build a company that someone’s willing to reach into their pocket to invest in and write you a check, you have a lot to be proud of,” right? To write a check for $165,00,000.00—that’s plenty to be proud of. But even beyond the money, when you look out at swampUP, when you look out at all those Frogs’ faces, you guys have a lot to be proud of, so congratulations.

    Ben Haim: Thank you very much.

    Shimel: Thanks for joining us.

    Ben Haim: Thank you.

    Shimel: And continued success. Hey, we’re gonna wrap it here in San Francisco from JFrog swampUP, this is Alan Shimel for devopsy.kinsta.cloud and the Digital Anarchist.

    — Alan Shimel

  • DevOps Tools Democratize the View From Both Sides

    DevOps Tools Democratize the View From Both Sides

    How modern product decisions platforms marry the key metrics of features changes to organizational KPIs

    In 1967, Joni Mitchell released one of her most iconic songs, “Both Sides Now.” The song was inspired by the book, “Henderson the Rain King,” in which author Saul Bellow writes about flying to Africa and looking out the plane window, “Look at those clouds down there; it’s very strange to look at the clouds from up above them. I remember as a boy having dreamed up at clouds a lot and having seen the cloud from both sides now, I suppose I shouldn’t really be amazed by anything.”

    Although not her intention and slightly before its time of popularity, the song speaks quite accurately to the tensions between idealized DevOps and the reality on the ground that many organizations are struggling through. On paper, the core tenant of DevOps is about cooperation, seeing problems and processes from multiple team members’ perspectives from each side, but this is easier said than done.

    “But now old friends they’re acting strange
    They shake their heads, they say I’ve changed
    Well something’s lost, but something’s gained
    In living every day.”

    The Unicorns and the Rest of Us

    Some of today’s most successful and disruptive companies—including Google, Netflix and Facebook—have taken their market-leading positions precisely because they have developed strategy and culture around DevOps. It has been part of the company DNA since the beginning and every employee is bought into it. This means fast, agile development and experimentation is part of the culture.

    While many companies would like to capture some of the benefits that unicorns have realized from implementing these development methodologies, for many, this simply is not an option. There is legacy infrastructure, processes and people—who are sometimes the hardest to change. Often DevOps is embraced in small pockets of a company, by teams with newer members working on new projects. The mindset shift that needs to happen to have DevOps—and everything that comes along with it—become part of a company’s culture takes time, commitment and perseverance. However, a good way to start is by demonstrating the fresh, diverse perspectives that can be gained through experimentation and progressive exposure to encourage wider adoption.

    Leveling Up

    One of the ways modern app delivery, operations and business management teams at organizations all along the adoption spectrum are achieving governance, operational awareness and control at speed is by wrapping new code deployments in feature flags and using a centralized platform to control progressive exposure to users.

    By themselves, feature flags are not new. What is new is the centralized and externalized control plane as a service and, newer still, the idea of observing system and business KPIs at the user session or request granularity level for feature flag-controlled decisions.

    When something is rolled out to 5% of the users, it is not likely to light up global ops or business metrics dashboards, even if it is a bit broken—and that makes people cranky. If instead, tools are in place to monitor the KPIs within that 5% population and compare it to the other 95% looking for divergence, you have a much more powerful early warning system.

    These new centralized platforms also extend observability to stakeholders beyond the few wizards driving orchestration and ops teams watching dashboards. An anti-pattern to the local control autonomy spiel modern DevOps patterns call for, this wider visibility protects against local optimization traps in which one team improves its KPI while degrading other KPIs it doesn’t know or care about.

    It can be beneficial to have the idea of key metrics tied to a feature and organizational metrics that look after larger organizational concerns. This inspiration can be traced back to what LinkedIn does with its XLNT experimentation platform, where it calls the organizational metrics “guardrail KPIs.” By always tracking a set of metrics that are critical to the business as a whole, organizations gain a clearer view of the impact that both the granular updates and the larger rollouts are making to the business.

    As Joni said in all her wisdom:

    “I’ve looked at life from both sides now
    From up and down, and still somehow
    It’s life’s illusions I recall
    I really don’t know life at all.”

    No team or organization can know everything all the time, but we can build in visibility to the process of rolling out functionality to our users and create a shared vision of our intentions and the results we achieve. I would argue that if you do look at DevOps from both sides, up and down, you will know the benefits.

    — Dave Karow

  • Successful DevOps Initiatives Start With Company Culture

    Successful DevOps Initiatives Start With Company Culture

    What initially drove the need for embarking on the DevOps journey in your team or at your company in the first place? Was it:

    • Market shift?
    • New leadership or an acquisition?
    • New product or service idea?
    • Cost savings or consolidation?
    • All of the above?

    Whatever drove the need, my guess is there were pre-sales demos, reorganizations and training on new tools that were promised to solve all your DevOps problems along the way. Now, I must break your heart just a little: Buying new tools or apps will not, on their own, ensure positive DevOps outcomes.

    A tool-first approach is ineffective. In fact, it may actually generate backlash from the individuals or groups who are invested in protecting the status quo and result in a wasted implementation effort. Imposing new methodologies or processes across teams through new tools can cause people to dig in, generating responses ranging from passive-aggressive to overtly destructive—both contributing to failure.

    It Starts With Culture

    Your success on the DevOps journey starts with culture. Culture transcends tools, methodologies and processes, making use of all but not relying on any. Culture was, and always will be, present, and much like continuous development—routinely referenced in DevOps—it is continuously influenced by everyone and everything in its environment.

    The successful implementation of DevOps must begin with a conscious effort to reassess and evolve a company’s culture, supported by the tools. For example, continuous deployment as an initiative will only find traction when members of the team all believe, philosophically, it is best for the organization. It requires a certain kind of individual.

    A culture of rapidly evolving and adapting teams focused on continuously discovering, developing and delivering demands a commitment to evolving toward a more contemporary integral DevOps toolset, not the other way around.

    Culture Alignment as a Competitive Advantage

    Cultural alignment is not a buzzword bingo box that gets checked off. One’s sense of alignment with a clearly articulated mission and set of values, coupled with a way of working in a team and supported by the right tools, generates velocity and efficiency. This alignment becomes a competitive advantage.

    But, doing so demands all participants to be more conscious of how what they do affects everyone and everything else, in real time.

    Culture Change is Difficult but Achievable

    It can be very daunting or even scary if your company culture has a long history, producing images of the Borg or Hive, depending on your age bracket. Changing a culture is difficult. Here are some thoughts on where you might start.

    Learning agility: Focus on learning to dance with VUCA (Volatility, Uncertainty, Complexity and Ambiguity) instead of being consumed by it.

    Diversity: Commit to working with people with wide-ranging intellect, backgrounds, titles, CVs, life experiences, ways of learning, gender and energy, instead of working with your mirror.

    Trust: Build a work environment based on psychological safety—a sense of confidence that the team will not embarrass, reject or punish someone for speaking up. Knowing takes time and deliberate effort.

    Leadership: Adapt and promote a leadership style such as the 3 C’s of change leadership–communicate, collaborate and commit.

    Coaching Culture: Consider championing a coaching subculture by applying a methodology such as LACE to work through difficult conversations:

    • Listen to understand.
    • Ask powerful questions.
    • Challenge and support with feedback.
    • Establish next steps and accountability.

    Worth It

    We started with a little heartbreak. But I have had enough conversations about DevOps success and failure to believe that you already knew it was not just about tools. We have all felt the weight of culture when it is not in alignment. Employing some or all of these recommendations will set you down the path of creating your own language that is a requirement for building a culture. Now stop looking at the next great messaging protocol and start working on building an agile, aligned culture.

    — Joshua Platt