devopsy.kinsta.cloud

Category: Enterprise DevOps

  • Transposit Survey Shows DevOps’ Impact on CIO, CTO Relationship

    Transposit Survey Shows DevOps’ Impact on CIO, CTO Relationship

    A survey of 415 CIOs and CTOs conducted by Transposit, a DevOps process orchestration platform provider, finds that as organizations continue to adopt DevOps processes more widely, friction between these types of senior IT leaders is rising within many organizations.

    As a C-level role, ‘CTO’ first gained traction in the wake of the dot com boom. In more recent years, many traditional enterprises added CTOs alongside CIOs as they realized how dependent the organization had become on software. In the wake of the COVID-19 pandemic, there is now more focus than ever on digital business transformation initiatives that are dependent on the timely delivery of software.

    Transposit CEO Divanny Lamas said that as more organizations’ structures revolve around product teams, there are a lot more CTOs. In some cases, CIOs are reporting to CTOs.

    The majority of organizations surveyed have both roles. A full 83% of CIOs said there is also a CTO at their organization, while 86% of CTOs said there is also a CIO. Just under a quarter of respondents (24%) said they perform both roles.

    At the same time, 98% of survey respondents reported increased focus on digital transformation within their organization in the past three years, with three-quarters (75%) noting that focus has increased since the start of the pandemic. A full 85% report their budget has increased over the last three years.

    Not surprisingly, 92% of respondents said that their responsibilities have changed in the last three years, with over half (56%) reporting their role changed significantly. Both are now graded according to key performance indicators (KPIs) related to managing revenue, with 66.3% of CIOs and 78% of CTOs saying their position is now either directly involved in or required to lead a business strategy.

    But only 34%, or just over a third, said that ownership of most aspects of digital transformation initiatives is a shared responsibility between the CIO and CTO. Specifically, just under a third (32%) noted ownership of software development in their organization is a shared responsibility. A full 88% of respondents apply DevOps practices, and 83.4% believe that DevOps is important to digital transformation at their organization. Almost all (98%) plan to expand their DevOps practice, and 83% already have a plan in place to do so.

    Lamas says software engineering-first principles are changing not just how applications are built but also how IT teams are structured in a way that advances innovation.

    More than a third (35%) of respondents said ownership of software operations developed in-house is a shared responsibility in their organization, while 28% said ownership of managing SaaS or operating commercial off-the-shelf (COTS) software in their organization is a shared responsibility. A third (33%) also noted ownership of the technology for the external customer experience in their organization is a shared responsibility.

    A full 95% of survey respondents also confirmed that the performance of their team is measured by key performance indicators (KPIs) related to revenue, specifically revenue growth (75%), rate of innovation (60%) and uptime (54%).

    It’s too early to say how the relationship between CIOs and CTOs will evolve, but the one thing is clear: The pressure for these roles to collaborate more effectively is on the rise.

  • MongoDB’s Atlas Turns Five

    MongoDB’s Atlas Turns Five

    In June 2021, Andrew Davidson, VP of cloud products at MongoDB, talked with Alan Shimel about MongoDB and the fifth anniversary of launching Atlas, the company’s database-as-a-service offering. The video is below, followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    Alan Shimel: Hi, everyone. Welcome to another segment here on TechStrong TV. Our guest for this segment is Andrew Davidson. Andrew, welcome to TechStrong TV.

    Andrew Davidson: Thanks, Alan. Good to be here.

    Shimel: It’s great to have you on. Andrew, I purposely didn’t say a lot about – I just said Andrew Davidson. I didn’t give your company, your title, or anything. I’m gonna let you do that, if you don’t mind.

    Davidson: Well, thank you very much. Yeah, so I’m Andrew Davidson. I’m VP of cloud products here at MongoDB. I’ve been here nearly nine years. I’m a Silicon Valley native originally, but I moved to New York City and found this amazing opportunity here. MongoDB, for those who don’t know, is actually headquartered in New York City. And it’s been an amazing journey since that time, just seeing this incredible explosive growth out there over this time.

    Shimel: Absolutely. Y’know, if you couldn’t tell from my funny French accent, I’m from New York originally. So I got into tech around 1995, 1996. And at the time, I think the mayor of New York was Mayor David Dinkins, and he had started a project that they were calling Silicon Alley. Right?

    Davidson: There you go.

    Shimel: It was downtown. And I actually had an office – first company I sold – on John Street, 55 John Street. But it was shortly after that – eh, shortly; it was probably seven or eight years after that at least, I bet, that Mongo started in that Silicon Alley, New York kind of cauldron of tech stuff.

    Davidson: That’s exactly right.

    Shimel: Yeah. Oh, I remember. I was in New York then. And it was a point of pride, actually, right? I mean, it wasn’t Oracle. We didn’t wanna be Oracle, right? It was the new guys, the new sequel guys, and they made a name for themselves and did well, right? And so I’m glad to hear you made that move from Silicon Valley –

    Davidson: Totally.

    Shimel: – to New York, and it’s a pretty cool thing. Of course that, as I said, was 15, 17 years ago, right? We’re here to celebrate a birthday/anniversary today, too, and that’s the – If I’m wrong, Andrew, correct me. It’s the fifth anniversary of Atlas from MongoDB, right?

    Davidson: That’s exactly right. We launched MongoDB Atlas, which is our global cloud database service, five years ago this month, and we’re just so excited. We’ve come so far. We’ve reached the psychological milestone this same month of 51 percent of our company revenue growing more than 70 percent year over year. We all know that this is the future of the platform. This is the foundation on which we can deliver really the world’s preeminent application data platform. And the value –

    Compared to where we were, y’know, when you mentioned when MongoDB was coming out of Silicon Alley so many years ago, it’s just a completely different universe today. At that time when MondoDB was first created, I think it was largely about timing. There was this combination of factors, giving developers this document model that was totally native for them, and also democratizing a distributed system right at the time in which cloud was democratizing commodity hardware.

    That combination led MongoDB to explode. But this idea of self-managing databases that we realized six, seven years ago, that was gonna go away. People are gonna move up a whole level of abstraction. It’s gonna be all declarative. An end-point in the cloud you can read and write from, and build wonderful applications – that’s what MongoDB Atlas was all about. And five years in, over 25,000 customers, over 100,000 developers signing up every month, it’s just unbelievable.

    Shimel: It really is. Y’know, I mean, look. Again, having been there, the original attraction with MongoDB was “no SQL,” right? It was a no sequel database. Everybody was using SQL scripts, and whether you were using MySQL or MS SQL, it was – And then the idea of no SQL was really huge. But why was it huge? I think you hit it, Andrew. Number one, it was easier for developers to do what they wanted to do, how they wanted to do it. Number two, it was just lighter and easier and more fungible, if you will, especially as we were moving to cloud in 2005 and 2006, right?

    Cloud burst on the scene. And it lent itself. It lent itself to multi-nodes and all of these things much better than relational SQL database.

    Davidson: Totally.

    Shimel: But of course Atlas comes in as a service.

    Davidson: Absolutely.

    Shimel: And I think that – it’s more than just a service. A database is a service, or data is a service. But fundamentally I think that is the next leap forward, right? We went from like 2001: An Odyssey, right? Someone _____ to throw a rock, and that was a big leap forward. But it was the next leap forward with fire, that defined it.

    Davidson: That’s right. The obelisk, I suppose you could say.

    Shimel: Right, the obelisk, no, totally.

    Davidson: ‘Cause I mean, like you were saying a second ago, why is it so important for developers to have a data model that’s so native for them? Well, it’s because every company today has that incredible sense of urgency that they must be come software companies. In every vertical, every part of the world, everyone’s either fighting to keep what they’ve got or being challenged by upstarts. And you can’t buy this off the shelf any longer.

    You have to bring that DNA in house and really reflect your company’s unique value propositions and users and internal logistics and all of the above for software, and data is the heart and soul of software. It’s always been the hardest part of, frankly, building software. We change how we build software. We layer in microservice as next-gen frameworks, et cetera. But if the data model hasn’t kept up, and if the data model continues to be this sort of tabular model that goes back to the ’70s, a time in which storage was the key bottleneck in computing because it was expensive to have storage then –

    We flash forward to today. The bottleneck is actually our technical people’s ability to understand and build that software. And so MongoDB flips this whole thing on its head and allows those people to be kind of these artisans of the business today, unlocking their ability to really make those businesses competitive. And that’s why I think the strategic value of this is rising. And then when you deliver it in a service, you get so far away from this kind of plumbing of dealing with infrastructure management, operating systems –

    Who wants to be talking about that stuff? It’s non-differentiating, right? You have to move to your custom software, and you have to be able to utilize the best-in-class capabilities. Best in class database as a service globally on the Big Three public cloud, like MongoDB Atlas. Use that with best-in-class other capabilities, and really weave together your unique business, your unique company. That’s what’s happening out there.

    Shimel: Agreed. You said something earlier, too, that wasn’t lost on me, and I wanna make sure it wasn’t lost on the audience. Here on the first anniversary of MongoDB Atlas, it now accounts for more than 50 percent of revenue for the company, which means it’s the dominant revenue-maker for the company. And how long are you working on the Atlas project now, Andrew?

    Davidson: Since the beginning. I mean, really five, six years on Atlas, but at MongoDB almost nine.

    Shimel: Yep. So I guess the question is, and be honest –

    Davidson: Yeah.

    Shimel: – don’t fudge it – did you imagine five years ago that this would be the dominant revenue source for Mongo? Or did you always think it was?

    Davidson: That’s a great question. I think part of me thought, “Y’know, it’s gonna be so hard to get to the point where you can be trusted to power the back end of these mission-critical applications all over the world. This is gonna be such a massive mountain to climb!” I think I had doubts at times, but on the flip side I knew: this is the future of databases. The only way we’re really gonna get to that next level, the only way we truly can disrupt this massive database market, is if we nail it with this service.

    So we knew, and I think we had pretty solid buy-in at every level of the company, that we had to make Atlas successful. In the early days, y’know, as is always difficult, we were kind of a start-up in the company, a whole new go-to-market model, largely self-service led, credit card customers coming in, long tail. We weren’t ready yet to go out to the enterprises on year one. And kind of earning that right, getting battle tested, getting all the security controls, the regulatory capabilities, the sort of the reference wins.

    Y’know, those early customers like 7-11, and Liberty Mutual, and NBCUniversal. Doing great big things on the platform, really showing that you could do it at scale, you could do it safely and securely. And just validating the value prop that we always knew was gonna be there – it just got easier and easier. The flywheel starts moving, and you started feeling like, “Y’know, we really have a shot, here.” And we started doing more and more deals – SMB, corporate, kind of mid-market segment.

    And then probably year three, we started really going big in the enterprise, and you just kinda knew, “It’s gonna happen. We’re gonna do this.” The growth rate was so high. And now, boom. Yeah, you get to that point. The 50 percent chasm is crossed, growing twice as fast as the traditional software, and it’s like, “What a feeling!” I talked to so many customers, even, who are transitioning from kind of being open-source software companies to SAS companies.

    It is a very hard DNA shift to go through. You go from really just writing software that other people run on their own, to being responsible for the business of your customer. And it’s a whole different trust dynamic that’s really important.

    Shimel: Absolutely. Look, congratulations to you and to the whole team with that. It’s an accomplishment, for sure, right? ‘Cause it’s easy to go from zero to one; it’s easy to go from one to two. Two to four is harder. Four to eight is harder. Eight to 16 is yet harder. When you’re talking about 50 percent of the revenue of a company like Mongo, it’s not a zero to one, right? Five years ago, Mongo was already – I guess it was public. Was it public five – ? I don’t know. How long – ?

    Davidson: I think we went public more – no, I think it was more like three and a half years ago, if I’m not mistaken.

    Shimel: It was still a sizeable amount of revenue, right? It wasn’t just _____, y’know –

    [Crosstalk]

    Davidson: Oh, yeah, absolutely. Yeah, yeah, totally. Yeah, yeah.

    Shimel: So that is a mountain to climb. All right. I’m gonna ask you – We’re running low on time. I got a few other things. I’m gonna ask you to put on your visionary goggles now.

    Davidson: Sure.

    Shimel: Here we are, Andrew, talking to Alan five years from now. I hope not. I hope I’m somewhere in Maui or something. But five years from now we’re talking, celebrating the tenth year of Atlas. It’s now 80 percent of Mongo’s revenue, unless something new came up to disrupt it – who knows?

    Davidson: Totally.

    Shimel: But what does Atlas look like five years from now?

    Davidson: Yeah, look. I mean, the whole philosophy of our platform in many ways is it’s fundamentally about user experience. It’s about making it possible for these application developers and operators and enterprises and start-ups, everyone in between – make it easier for them to build modern applications on a modern application data platform. And what we think makes us really unique is, it all starts with this document data model. The document data model is very much the superset data model.

    You can express key value inside a document. That’s just, y’know, a document with a single index. You can express relational inside a document; it’s essentially a flat document. Y’know, spatial, graph – it’s all expressible in this unified interface. So you can do all these data models and all these use cases, which makes it very widely applicable, very multimodal. But then the important step beyond that is to drive multiple workloads behind the scenes.

    The workloads are kind of how you store the data behind the scenes, the algorithms you use to analyze it. Our philosophy is, behind that same unified, elegant interface, you should be able to express all of the wide array of workloads that power modern applications – operational, transactional, the most mission-critical applications; search, which is about human-powered experiences; mobile experiences on iOS and Android devices, synchronizing data back up and down from the cloud to the mobile device –

    real-time analytics; data-like use cases, with object storage economics. All of that should be accessible at your fingertips through this superset data model. And when we think about kind of wrapping all of that up, continuing to deliver it at scale, secure, highly available, highly scalable, multi-cloud service on the Big Three public cloud, we’re just gonna keep taking this vision to the next level. Be laser focused on the user and on delivering what they need to build the next-generation applications of tomorrow.

    Shimel: I love it, man. Good stuff. Andrew, we’re about out of time. For people who wanna get more information on MongoDB Atlas, where do they go?

    Davidson: Well, you can absolutely go to mongodb.com, but you should also check out our upcoming developer conference, mongodb.live, on July 13. Look forward to seeing you there.

    Shimel: Is that virtual only?

    Davidson: Virtual. Absolutely. Virtual conference this year. Next year I’m hopeful, very hopeful, we’ll be back with the real deal, what we used to call MongoDB World, in New York City.

    Shimel: Absolutely. I’ve been there, been there more than a few times.

    Davidson: There you go.

    Shimel: I’m looking forward to it.

    Davidson: Absolutely.

    Shimel: Y’know, I’m gonna be in New York that week of July 13th. I wish you guys were doing it in person. But –

    Davidson: Well –

    Shimel: Next year. We’ll wait.

    Davidson: Yeah, yeah. Look forward to seeing you _____.

    [Crosstalk]

    Shimel: Andrew, congrat – Absolutely. Andrew, congratulations on your fifth anniversary with Atlas, and great work. It’s something to be proud of, man.

    Davidson: Thank you, Alan.

    Shimel: It’s good stuff. Big stuff.

    Davidson: My final comment is, this community’s growing like crazy. Like I said, 100,000 people sign up for Atlas every month. You should sign up today if you haven’t experienced a free forever sandbox cluster, build your Hello World application. We’ve got courses for you to learn from, documentation up the wazoo, because this is big tent community. Thank you, Alan.

    Shimel: Absolutely. Talk to you soon, Andrew. A pleasure. Andrew Davidson, MongoDB. Fifth year anniversary of Atlas – check it out. We’re gonna take a break here on TechStrong TV, and we’re gonna be right back with another guest.

    [End of Audio]

  • DevOps Dozen² Awards 2021 Nominations Now Open

    DevOps Dozen² Awards 2021 Nominations Now Open

    The DevOps Dozen² Awards are back and open for nominations. This past year has been quite a journey and we are very proud of the DevOps community in their ability to pivot, innovate, adapt and think ahead in these challenging times. Some outstanding leaders and vendors have worked nonstop to reach their goals and achieve the highest level of success. We are thrilled to celebrate their hard work and achievements.

    The DevOps Dozen² Awards honor the most dedicated and inspiring thought leaders and innovators who have made significant contributions to the community. For the second year, we have expanded our awards program to include two different DevOps Dozen sections: DevOps Dozen Tools and Services Awards and the DevOps Dozen Community Awards.

    There are 12 awards for each section:

    • DevOps Dozen Tools and Services Awards — Recognizing the companies that develop and deliver outstanding solutions to empower developers, DevOps and IT operations teams.
    • DevOps Dozen Community Awards — Honoring the leaders who have made a positive impact in the DevOps community.

    Nominations are made by the audience. Anyone can nominate a tool or service, although there is a $250 entry fee for the Tools and Services Awards nominations. We implemented this fee last year to cut down on spam and superfluous nominations. However, there is no fee for Community Awards nominations. Please note that commercial tools and services are not eligible for the Community Awards and will not make it through to the finals.

    Finalists will be selected and winners will be chosen from among the finalists. The finalists will be determined by general public voting (weighted for 40% of the final total) and our judges’ selections (weighted for 60% of the final total).

    The last day to submit your nominations is October 22. To vote, follow the steps outlined on the DevOps Dozen² website.

    Who Are the DevOps Dozen² Judges?

    The following DevOps experts make up the DevOps Dozen² Awards 2021 panel of judges, and will review the submissions made by the public and choose the winners:

    • Alan Shimel, founder, CEO and editor-in-chief at MediaOps
    • Jayne Groll, co-founder and CEO at the DevOps Institute
    • Mitch Ashley, founder and CEO at Accelerated Strategies Group
    • John Willis, senior director of the Global Transformation Office at Red Hat
    • Helen Beal, chief ambassador at DevOps Institute and ambassador at Continuous Delivery Foundation

    The 2021 DevOps Dozen² Categories

    DevOps Dozen Tools and Services Awards

    • Best End-to-End DevOps Tool/Service

    Consolidation in the DevOps space has led to a greater selection of platforms offering end-to-end solutions. This award honors the platform with the most diverse and robust solution for DevOps teams.

    • Best DevOps Repo/GitOps Tool/Service

    Git has led to GitOps and it has become an integral part of the DevOps toolbox. This award is presented to the most outstanding Repo/Git/GitOps tool.

    • Best CI/CD Tool

    This award recognizes the best CI/CD tool that helps teams to deliver quality code better.

    • Best Value Stream Management Tool

    Value stream management has come into its own as an important tool for measuring the business value of DevOps and application development. This award recognizes the value stream management tool that most effectively helps visualize the value stream, track metrics and measure improvement.

    • Best Observability Solution

    This award recognizes the best observability solution for observing and monitoring to understand the performance of individual components and systems and entire applications.

    • Best DevSecOps Solution

    This award honors the best DevSecOps solution, which enables security to be included earlier and continuously throughout the SDLC.

    • Best Testing Service/Tool

    Testing is a mainstay in the DevOps toolchain. This award recognizes the best testing tool for ensuring the quality of code.

    • Best Kubernetes Platform/Service

    The adoption of containers has paved the way for an entire solutions ecosystem supporting and enhancing the container technology. Kubernetes is perhaps the most widely recognized and utilized tool in the space. There are many platforms and services that offer Kubernetes-based solutions. This award honors the best Kubernetes platform/service available.

    • Best Cloud-Native Security Solution/Service

    The cloud-native movement has taken the IT world by storm due to the depth and breadth of the solutions available and the benefits of building applications and services specifically for cloud-native environments. This award recognizes the best tools, solutions and services considered cloud-native.

    • Best DevOps for Mainframe Solution
      Mainframes are far from being the dinosaur of the IT world, and a variety of solutions are available for enabling DevOps practices in mainframe environments and hybrid environments. This award recognizes the best of them.
    • Best DevOps for DataOps/Database Solution
      Databases often have been left out of the DevOps conversation, but that is changing. The whole concept of DataOps is gaining greater traction. This award recognizes the best solution in the database for DevOps and DataOps categories.
    • Best New DevOps Tool/Service Provider
      This award recognizes the best new service provider or tool that has brought innovation to the DevOps space in the past year (must be less than 24 months old).

    DevOps Dozen Community Awards

    • Best DevOps Industry Implementation
      This award honors organizations that have successfully adopted and implemented DevOps principles and practices.
    • Best DevOps Survey/Analysis/Research
      This award recognizes research that has significantly and positively impacted the DevOps community.
    • Best DevOps-Related Video Series (video)
      This category highlights the most entertaining, educational and inspirational DevOps video series—those with the most engaging and highest-quality content.
    • Best DevOps-Related Audio Podcast Series
      Which is your favorite DevOps podcast from this year? This category celebrates the many great DevOps podcasts sparking some interesting discussions on a multitude of topics from CI/CD and testing to DevSecOps, Kubernetes, containers and more.
    • Best DevOps Book/eBook of the Year
      Each year sees a plethora of well-crafted DevOps-related books and ebooks. This category highlights the most popular and best read of the year.
    • Top DevOps Evangelist
      This category is one of our favorites. There are so many great evangelists who spread the DevOps gospel and we want to know who does it best. Nominees can work within the DevOps space or outside of it.
    • Best DevOps Transformation (non-vendor)
      In a year in which digital transformation became a must-have for survival, we want to know which organizations stood out in their efforts to transform their business through DevOps.
    • Best DevOps Virtual Event of the Year
      COVID-19 has changed the game when it comes to hosting events. In 2021, virtual events remain the norm, reaching a global audience while everyone stays safe at home. Which DevOps virtual event stands out from the others?
    • Most Innovative DevOps Open Source Project
      Open source projects are meant to promote innovation and increase efficiency, velocity and quality. While there are many great open source projects out there, the best ones are those that create a community of people who work on and with the technology and support each other.
    • DevOps Executive of the Year (non-vendor) This category celebrates excellence among DevOps leaders at the C-suite (or equivalent) levels.
    • Best DevOps Presentation of the Year
      This category recognizes the best DevOps-themed presentation from the many (virtual) conferences during the year.
    • Best DevOps.com Article of the Year
      DevOps.com publishes multiple new articles every day. Which was the best article from 2021? Let us know so we can recognize the author.

    All the solutions nominated to the Tools and Services Awards will automatically be registered into the DevOps Tools Guide authored by MediaOps and Accelerated Strategies Group. This initiative is our effort to create a comprehensive listing of tools and tools vendors to help end users better understand the DevOps market landscape.

    Choosing a winner is difficult when there are so many talented and inspiring leaders doing an incredible job to empower and support our community. Although not everyone can win an award, being nominated says a lot about each and every one of you. We greatly appreciate your dedication and service to the DevOps community.

    For more information, please visit the DevOps Dozen² website. If you have any questions regarding entry process, awards, timing or any technical issues regarding the website, please contact us at DD@devops.com.

    Alan Shimel

    CEO, MediaOps

  • Solving the DevOps Accountability Problem

    DevOps accountability is the idea that both the development and operations teams have equal responsibility for success. But putting this approach into practice has been a thorn in the side of DevOps teams for the past decade, largely due to outdated organizational structures that place responsibilities on a single employee or team.

    These outmoded structures restrict the lean flow of operations needed for DevOps and contribute to costly downtime when issues arise. But redistributing functions across the organization can help solve this problem. 

    For cross-functional teams that rely on organization-wide collaboration, redefining the org chart can clarify ambiguities about accountability and help organizations overcome internal obstacles.

    Legacy Organizational Structures

    Many organizations have not instituted an organizational structure that reflects a shared accountability model. This is partially due to leadership’s assumption that large teams work faster and more dynamically. In reality, after a team exceeds nine individuals, the rate of return diminishes and people are more likely to assume someone else on the team will take responsibility for a task. As a result, accountability falls through the cracks.

    Additionally, there is frequently an imbalance in assignments and responsibilities between junior and senior employees. When senior employees take on the majority of important or interesting tasks, junior employees can feel overlooked and less responsible for their team’s success. This is both an individual and a company-wide issue; younger workers tend to bring fresh perspectives and insights—they can also adapt more quickly to unprecedented changes and issues.

    Picture a team consisting of a line manager and team members, with a structure that places all major responsibilities on the manager. If the manager happens to be out of the office when an issue arises, the team would have to wait for their boss’s return to resume operations.

    But the consequences of single-point accountability go far beyond lost time and downtime costs. When employees feel like they don’t have a significant stake in a project, they feel less aligned with the organization’s overall purpose and are less likely to be engaged.

    DevOps is most effective when teams are built around a common goal rather than around the performance of individuals. If an employee can’t see the impact their work is having on the overall organization or project, it can create blind spots and disconnect between the business and its people. Shifting business frameworks is no easy feat, but with the right strategy, it can improve how tasks and responsibilities are allocated in your organization.

    Three Ways to Switch up Your Org Chart for Greater Accountability

    The days of allowing responsibilities to fall on a single employee are over. But to successfully embrace a shared accountability approach, you need to reimagine your entire organizational chart. Beyond de-prioritizing seniority and minimizing team sizes, consider these three initiatives to help settle DevOps accountability issues:

    1. Blueprint your organizational structure around products. Organize your work structure around products—not projects. Traditional project management models rely on passing responsibilities between specialized teams, which can slow down innovation and degrade the quality of work. With an organizational structure built around products, you can build a cross-functional team with all necessary skills for each system. For example, if you have a team that’s accountable for the payroll system, all necessary expertise you need to keep that system running smoothly is based on a single contact point.
    1. Redistribute talent. The product-oriented approach requires changing up talent distribution across teams. Let’s say you have a 24-person team for a single SaaS product and seven of those team members have similar skill sets and backgrounds. In this instance, you could move several of those workers to a different team where their skills are in demand.
    1. Establish hybrid workplace environment norms. Face-to-face communication has always been a critical part of successful teams. But in light of the COVID-19 pandemic, workplace norms are evolving and organizations need to adapt to new ways of working. Many teams are no longer able to participate in informal knowledge sharing and other typical in-office interactions, so it’s critical to identify new norms for your team. Initiate conversations about applying DevOps concepts in a hybrid world, along with creating rules of engagement and accountability that are realistic for remote work.

    The Great Redistribution

    As technology advances, so should your organizational structure. To optimize efficiencies and ensure products reach the market on time, consider rethinking your org chart. In practice, this will enable you to more seamlessly adopt a culture that celebrates shared responsibility and employees who feel they have a stake in your product’s future.

  • Meet the New(ish) Pipeline

    Meet the New(ish) Pipeline

    My company keeps a sample project running pretty much all of the time. Our current project (multi-target web/Android app using Java and Spring built with Gradle and Ant that we’ll call “Finder” here) is getting a bit long in the tooth, so we have been casting about for a new one over the last several months. From non-work sources, we came upon the idea of multi-targeted Godot with C# as a viable side project. Moving to a completely different set of tools is kind of the point; it makes us stretch, and that is the idea of our ongoing projects. The stated goals for these projects are:

    1. Stretch knowledge about different languages, DevOps tools and platforms.
    2. Keep doing what you all are doing. Too many pundits have “grown out of” hands-on work, and it shows.
    3. Try out new ideas/architectures.
    4. Avoid “kitchen sink.” We can’t have a current test app that includes all available technologies, so keep it streamlined. Approach this as a production app that we use for testing, not as a test app.

    That’s why we’re looking to replace our Java/Spring project. We’ve got that pipeline down, we’ve tweaked the app until we are happy with the core and it hasn’t changed in a good while. But change is a part of DevOps, so we’re off.

    The Obvious

    Let’s take care of the obvious elements in our toolchain right away:

    1. Git. We’ll use GitHub, but it was a given that some form of Git would be holding our code.
    2. Visual Studio Code. We’re doing C#, so this is going to be the most useful option for code editing. The built-in Godot editor is good and will be used, but VS-Code offers C# functionality add-ons.
    3. Antsle is the deployment tool of choice, though this has changed over the years. We’ll use it to set up install sets for clients.
    4. Jenkins or Hudson. We’re going to use this only for test management.

    The Less Obvious

    There are several constraints we want to (or have to) meet. First, we want to avoid using Jenkins or Ant to control the entire build process, mostly because we’ve done both in previous projects, and most DevOps teams are no longer using these methods for new projects. Second, this is a sample we keep, not an investment, so we want to use open source technology if at all possible, to keep expenses down. Third, we’re using a game engine to do app development. This has some impacts–like most game engines, it is in control at runtime and we need to bundle the engine in the final application.

    1. The Godot Engine. Godot is written as a game platform, but its graphics/cross-platform abilities make it useful for graphics-heavy apps like ours. But we have to include the engine and its config files in the pipeline.
    2. Code Scanning. Static analysis was a late addition to Finder, and it’s in Java. This project is in C# and Godot Script. We have not yet found a tool that supports Godot Script, but C# we can get; it just adds restrictions. So we will use a static analysis tool, but we’re still deciding which.
    3. Build Automation. We’ve used Jenkins, Gradle, Maven and Ant to handle this step at different times in the past, but something newer would be a good idea. We are still evaluating this step. We will likely end up back on one of those tools because they are still used today. Godot is a new element to us, so we are also evaluating what is required to hook into it and make functioning apps in a repeatable process.

    Fueled Innovation

    We’re having fun—first couple sprints have us running a working prototype, so we’re happy with that. There’s still a lot to implement in the app and in the pipeline, so we’ll no doubt have more to say here soon. We’re talking about putting a server component in—not because the original concept needs it, but because our outgoing app—Finder—had server and client sides, and our need for things like Postman go away without this architecture. And yet, API security, testing, etc. is an important part of the DevOps architecture. As you can see, we’re still iterating.

    As to Finder, we normally take down the pipeline for a previous playground project when the new one goes up, but Finder costs us little. There are five containers (three permanent for the app hosting; two for build/test) and some processing power, so we’ll probably keep it since it is using a different set of pipeline tools (and languages—it is mostly Java/JavaScript).

    Meanwhile, you all keep rocking it. We’re building an(other) app that no one but us will ever see—but you are keeping the enterprise humming. Kudos to you!

  • New Relic Survey Shows Greater Appreciation for Observability

    New Relic Survey Shows Greater Appreciation for Observability

    A global survey of 1,300 software engineers, developers, IT leaders and executives found half of respondents (50%) are in the process of implementing an observability platform. Another 23% of respondents said that they cannot gain end-to-end observability at all, while 26% said they believe they have mature observability practices in place. The survey, published today, was conducted by CITE Research on behalf of New Relic.

    The majority (94%) of IT professionals said observability is important for their job role, while nearly three-quarters (74%) said there is still room to grow their observability practice. In fact, 81% of the 450 C-suite executives that participated in the survey said they expect to increase observability budgets in the next year, with 20% expecting those budgets to increase significantly.

    Overall, the survey finds that lack of resources (38%), skills (29%), understanding of the benefits (27%) and strategy (26%) are top barriers to achieving observability.

    Observability, in one form or another, has always been a core tenet of DevOps best practices. Most DevOps teams have relied on monitoring tools to observe a specific process or function. The challenge is those monitoring tools track a pre-defined set of metrics such as resource utilization. Ideally, observability combines metrics, logs and traces—a specialized form of logging—to instrument applications in a way that makes it simpler to troubleshot issues without having to rely solely on a limited set of pre-defined metrics.

    Nearly three-quarters of respondents (72%) noted that IT teams today need to toggle between at least two different tools to manage IT, with 13% having to use more than ten different tools to monitor the health of their systems.

    In contrast, observability platforms make it possible to correlate events across both applications and infrastructure. This capability makes it easier for analytics tools to identify anomalous behavior indicative of the root cause of an IT issue. Armed with these insights, it becomes a lot simpler for IT teams to resolve issues faster.

    The New Relic survey notes that 60% of respondents still monitor telemetry data at the application level, which indicates that a massive amount of valuable telemetry data is largely going unused. A full 91% of IT professionals that responded to the survey noted that observability is critical at every stage of the software life cycle, especially when it comes to planning and IT operations.

    Top benefits cited include faster deployments (27%), more cost-effective use of IT resources (25%), better digital experiences (23%) and improved productivity (22%). The top use cases cited involved digital transformation initiatives (42%) followed by cloud optimization (37%), DevOps processes (36%) and bringing products to market faster (36%).

    Buddy Brewer, group vice president and general manager for New Relic, said observability will become a more pressing issue in IT environments, thanks to the rise of microservices-based applications running on Kubernetes. A full 88% of IT decision-makers New Relic surveyed said they are exploring Kubernetes and containers at some level right now, but only 10% said they have deployed them in a production environment. A total of 40% expect to be in production within three years.

    In general, it’s become critical for IT teams to be able to query data in real-time to resolve issues that are becoming more challenging to resolve at a time when organizations have never been more dependent on IT. Sampling data in the hopes of discovering issues is no longer sufficient, noted Brewer.

    The challenge, of course, is that most IT teams have been using legacy monitoring tools for so long that it’s still hard to imagine there might be a better approach. That doesn’t necessarily mean all those legacy tools will be immediately replaced, but it does mean many of them may simply fade away over time.

    One way or another, most IT teams will soon be able to observe IT environments more deeply. Developers increasingly are taking advantage of open source tools like OpenTelemetry to instrument applications in a way organizations can more easily afford, regardless of whether they fully appreciate the nuances of modern observability versus traditional monitoring.

  • JFrog Acquires Upswift to Push DevOps to the Edge

    JFrog Acquires Upswift to Push DevOps to the Edge

    JFrog today revealed it has acquired Upswift as part of an effort to extend its DevOps reach to edge computing platforms. Terms of the acquisition were not disclosed.

    Upswift has created agent software that is deployed as a binary file on an edge computing platform that makes it possible to continuously deliver software across a fleet of edge computing devices and platforms. That approach makes it possible for organizations to deploy software regardless of whether the target platform is only running Linux, containers or a virtual machine.

    JFrog CEO Shlomi Ben Haim said the agent software developed by Upswift will be integrated with the continuous integration/continuous delivery (CI/CD) platform created by JFrog to make it easier for organizations to manage the full life cycle of application workloads deployed on edge computing platforms.

    JFrog Upswift

    Organizations that deploy software on edge computing platforms and devices today typically have massive backlogs of updates that they are unable to deploy in a timely manner, said Ben Haim. By connecting the Upswift agent software to a (CI/CD) platform designed from the ground up to support binaries, it becomes possible to reduce that backlog as part of what JFrog describes as its ‘liquid vision’ for deploying software, he noted.

    In addition, after acquiring Vdoo to gain access to a set of analytics tools that discover vulnerabilities in application binaries, JFrog will also be able to bring DevSecOps best practices to edge computing applications as well, noted Ben Haim.

    The number of application workloads being deployed on edge computing platforms is rising sharply as organizations seek to process and analyze data closer to the point where it is being created and consumed. In fact, that shift is at the core of digital business transformation initiatives that depend on edge computing platforms and devices running, for example, internet of things (IoT) applications to process data in near-real-time.

    Upswift CEO Amit Ezer said it has already become apparent that the existing processes of updating software on edge computing platforms and devices are capable of handling that influx of software. Upswift created its tool to enable developers to assume more control over those processes, as responsibility for managing and securing software continues to shift left, he added. The issue in many cases is that organizations lack the ability to consistently deploy software on edge computing platforms, which results in a hodgepodge of homegrown tools being created to deploy software on edge computing platforms using largely manual processes.

    It’s too early to say just how much software will be deployed on the edge, but there may come a day when there is more software at the edge than there is in the cloud. Of course, the real challenge will be unifying the management of DevOps processes, regardless of where any given piece of software might be deployed. In fact, as edge computing continues to evolve, the line between edge computing and cloud computing will continue to blur until they are little more than natural extensions of each other.

  • 3 Building Blocks for Enterprise Digital Transformation

    3 Building Blocks for Enterprise Digital Transformation

    DevOps has gone from a new idea to a buzzword in every boardroom over the last decade. With society increasing its reliance on digitization and pushing their preferences for speed and convenience, enterprises of all types have had to change their business culture to help their teams to work together with greater speed and autonomy.

    While the pandemic has undoubtedly heightened the importance of DevOps in the workplace, its widespread use predates the last few years. HGS Digital research from as far back as 2018 found that only 3% of software development businesses had never heard of DevOps. The 2021: Future of the Atlassian Ecosystem report revealed that 54% of organizations have implemented a DevOps strategy—up from 48% in 2020. A further 27% of respondents are hoping to adopt a DevOps strategy in the next three years.

    Indeed, DevOps is now mainstream, and the uptick in job listings for ‘DevOps engineers’—as well as enterprises’ quickness to tout their ‘experienced DevOps teams’—is perhaps further evidence of this. However, some of these postings and sentiments can also be considered red flags as they suggest that organizations are applying DevOps practices to isolated teams. Or worse, they are simply labeling traditional engineering roles with the DevOps label rather than implementing a complete mindset shift that applies to the entire organization and enables it to release reliable products at a much faster pace.

    With this in mind, here are three key building blocks for enterprises looking to avoid common downfalls and effectively scale their DevOps strategies. These will help them change the way they work and think across all aspects of development and operations.

    Changing Culture and Empowering Employees

    Everyone needs to be on board for DevOps to be successful, and buy-in is strongly dependent on the business culture they are working within. For example, Gartner predicts that through 2022, 75% of DevOps initiatives will fail to meet expectations. And the reasons why have to do with issues around organizational learning and change.

    To put it another way, if employees don’t understand DevOps’ deeper thinking and benefits both to them personally and to the wider group, they will naturally be resistant to the change. It is, after all, an entirely new way of thinking for many departments, especially operations teams who traditionally reduce risk by minimizing change and taking things slowly. DevOps encourages them to speed up with minor changes delivered through continuous integration operating in a fail-fast and often fail-forward pipeline.

    Therefore, educating employees is vital for success. In particular, organizations should give staff a clear idea of how it will feel to work differently. Shared definitions of success, shared vocabulary and shared visibility of the work to be done is key. With that—and along with sharing actionable insights that teams can apply to their work and then observe the results—no matter where they are in the pipeline, the real value of DevOps can be achieved.

    The reality is that people are the most critical component of any DevOps transformation, making their commitment to the cause non-negotiable for success. Despite the tech-heavy nature of software development, soft skills like communication, collaboration, flexibility and decision-making must be prioritized as much as security, coding and infrastructure knowledge. It’s imperative that all businesses look to adopt a DevOps mindset and implement these traits into their culture in the future.

    Applying Four Fundamental Processes to the Foundation of DevOps

    That said, a successful DevOps transformation can’t happen unless enterprises step away from traditional IT’s ‘trust but verify’ methodology. Instead, they must incorporate a set of essential processes that empower everyone to work more efficiently and effectively toward achieving faster, high-quality software delivery to suit the end-user’s needs. These fundamental processes include collaboration, automation, continuous integration and continuous delivery (CI/CD) and monitoring.

    While collaboration has been one of the most significant rallying cries for enabling globally distributed IT teams to align their goals and meet their objectives, automation has also been highly crucial. Many of those ingrained in DevOps environments will tell you that automation is what makes DevOps highly valuable. It helps teams achieve high levels of efficiency and allows employees to focus more on complex problems and less on repetitive tasks. When a company’s automation strategy is aligned with its broader business goals, it can help deliver value at scale.

    But as is the nature of software development, problems can arise. And this is where continuous integration and delivery come into play; it forces developers to merge their source code updates with others far more frequently than they might otherwise choose to. Operations teams can ensure they’re not creating a bottleneck with manual testing to get releases out to users. The approach means smaller changesets; helping to identify, target and resolve bugs more efficiently. This increases the flow of work, the quality of releases and helps to avoid nasty problems at the end of the development cycle.

    But there’s no point in having a speedy, heavily automated CI/CD process with a genuinely collaborative culture if enterprises don’t take the time to measure what’s working and assess which actions need to be improved. This is why an effective DevOps plan needs to be built on the mantra ‘implement, measure and improve’. After all, DevOps is about maximizing value and efficiency through increased visibility of work and constant feedback. Measuring real-time metrics becomes vital to ensure business’ transformations are in line with their objectives at all times. If enterprises stick to these fundamentals, they’re well on their way to a successful DevOps strategy with complete buy-in.

    Adopting the Right Tools for Transformation

    As teams grow and DevOps processes scale, predictable performance is imperative. Therefore, the enterprise’s tools must be available around the clock and should perform at a high level to support their collaborative pipeline.

    But using DevOps tools doesn’t automatically mean organizations are applying DevOps principles. The value of tooling is limited by businesses’ commitment to using them holistically with the sort of culture and processes mentioned above. It is this combination that allows them to transition how they develop and deliver their products. With all that said, it’s important to understand how important it is to adopt the proper toolchain—and the wide variety of choices and combinations available—this is why it’s easy to understand why decision-makers might become overwhelmed.

    After all, there’s a lot to keep in mind. They need to choose tools that step up their collaboration, keep context-switching to a minimum, aid automation, encourage visibility and allow for effective monitoring. But there’s also the risk that they’ll pick the solutions that they feel most comfortable with, which can be counterintuitive to transformation. This approach can lead to a tool binge, bringing on too much technology where integration isn’t a priority, and leaving enterprises with nothing that does the job they need.

    With this in mind, enterprises need to take the time to consult on which tools are right for them while constantly keeping the fundamentals of DevOps in mind. To illustrate just how valuable this is, DORA and Google Cloud’s 2019 State of DevOps report found that the highest performing engineers are 1.5 times more likely to leverage easy-to-use tools. Meanwhile, failure to do this is perhaps a primary reason why a separate study from the DevOps Institute uncovered that the DevOps transformation journey is still arduous for more than 50% of respondents.

    Taking the Next Step Toward DevOps

    A successful DevOps transformation rests on in-depth understanding, mass buy-in and an organization-wide adoption of fundamental principles and practices. When this agile mindset is applied to the people, processes and tools that make up an organization, enterprises can drive significant change across their teams while increasing their products’ reliability, stability and security.

    It’s always important to keep in mind who DevOps is designed to benefit the most—the customer. This mindset is particularly valuable in today’s landscape, where businesses and consumers alike are flush with more choice than ever. With speed and convenience now at the forefront of most people’s purchasing decisions, DevOps can play a huge role in helping organizations strive for greatness and offer the customer something they didn’t even know they needed. Using the above building blocks, organizations of all sizes can dramatically improve their customer experiences and work more efficiently to quickly get the right products into their hands.

  • 4 Ways to Simplify Cloud Performance Monitoring

    4 Ways to Simplify Cloud Performance Monitoring

    Over the past 18 months, technologists across the globe have played a crucial role in the survival of brands and organizations via digital strategies. Across all industries, their skill and dedication have enabled businesses to rapidly launch innovative new digital services to meet huge fluctuations in customer needs and allow entire workforces to operate from home during the pandemic.

    This hasn’t been easy, even as end users’ expectations for seamless digital experiences are on the rise. In fact, the recent 2021 App Attention Index reaffirmed found 76% of consumers’ expectations of digital services have increased in the last year. And an overwhelming 85% noted that applications and digital services have become a critical part of their daily lives. This has placed even greater pressure on the technologists who are responsible for keeping applications and cloud experiences running smoothly.

    Often IT teams are challenged with monitoring companies’ digital services, but they lack the visibility they need to monitor health and performance across an increasingly sprawling IT estate, exacerbated by a seismic shift toward cloud architectures over the last 18 months. IT departments don’t yet have the right tools and data to optimize health and performance in their cloud environments.

    As a result, technologists are constantly addressing the same issues because they can’t easily isolate and identify them, and don’t know where to prioritize their actions. Hiccups can lead to brands losing customers—the same report revealed that over half of consumers indicated that brands have one shot to impress them, and that if their digital service does not perform, they won’t use them again.

    After a year and a half since the start of the pandemic and with adoption of cloud technologies set to accelerate even further over the next few years, it’s time for technologists to get ahead. Here are four things technologists can do to take the stress out of managing performance across the cloud.

    Implement Visibility from the Ground Up

    Having visibility into applications and the underlying cloud infrastructures that support them can be challenging without the right tools, which has contributed to some of the pressure technologists are experiencing. Traditional monitoring has allowed technologists to identify and catch issues in certain areas of an IT stack, but this approach is of little use in dynamic, distributed and software-defined environments where organizations are continually scaling their use of IT and the cloud up and down.

    As a result, the performance of the digital services can be impacted, potentially hurting end-user experience and eroding trust in the brand.

    To keep up with the rising demands from consumers in the digital world, technologists need the ability to monitor the full IT estate, from cloud infrastructures to customer-facing applications through to core infrastructure such as compute, storage and network; including the open web and security. With access to tools like observability platforms, technologists can lessen the burden of individually monitoring the performance of each item supporting the digital service. Instead, they can achieve one holistic view into alerting, root cause and analysis of correlated metrics, events, logging and tracing (MELT) data from the cloud to enable early and easy troubleshooting.

    Consider tools that link infrastructure (compute, storage and network) with the services and applications they execute. When there is an application-level issue, it is easy to take a closer look and identify problematic areas in what makes the application run or the application itself.

    Align IT Performance to Business Results

    After aggregating a full-stack view of applications and the cloud infrastructure behind them, technologists can then link performance data identified by the observability platform with real-time business metrics.

    Linking the two provides technologists with the ability to identify where and how the digital services are impacting the business and end-users. Full-stack observability automatically provides technologists with these linked insights, enabling them to address the areas that matter most.

    Educate Teams

    In addition to having the right tools to help take advantage of the cloud, it is important that an IT team is well-versed in the technology itself. Managing the performance of the cloud is complicated and there is a finite pool of talent available to businesses. Therefore, business leaders should provide appropriate resources to ensure teams are educated and equipped to succeed.

    To support a seamless implementation of cloud infrastructure to support a business’ digital services, business leaders must invest in upskilling their teams or recruit others who are knowledgeable about cloud monitoring.

    This will ease the pressure on existing teams and give technologists the skills and confidence to progress in their careers.

    Leverage Automation

    Even with the best observability solutions in place and teams equipped with the necessary skills, there is still concern that there will be an overwhelming amount of data generated by accelerated digital transformation over the coming years, especially those involved in large-scale public cloud environments. It can become a challenge for technologists to dedicate the level of resources and skills required to manage and optimize performance across the IT estate.

    To avoid these potential circumstances in the future, it’s worth considering how to minimize the impact of a data deluge by reducing an IT department’s reliance on manual interventions to monitor health and performance and resolve issues.

    Two things that will play an increasingly vital role in tracking health and performance across the entire IT estate are automation and AI. This is particularly the case in large-scale public cloud environments, which are fast becoming the biggest headache for some IT teams.

    With AI deployment to identify and fix issues in real-time, technologists can spend less time firefighting thanks to the AI/ML guiding hand. This will lead to increased job satisfaction and fulfillment and a better work-life balance.

  • How Does That Stack Up?

    How Does That Stack Up?

    There’s an entire class of successful innovations made up of things that people didn’t realize they needed. Things that were an obstacle they found a way around and didn’t think about until the innovation showed them an easier way. Think of things like virtualization (hardware was the bottleneck, but “That’s just the way it is,” until it wasn’t) or web monster shopping sites (“They don’t have that in the stores; I guess I’ll live without,” until you could order the weirdest or smallest things from the likes of eBay and Amazon).

    My rule here is that I only talk about products and services if I use them and find value in them. And even then, I try to do it sparingly. But in the spirit of the innovation story you just read, I’m going to point you at one of the coolest new websites on the net. I don’t know the company; have not done business with them, couldn’t even name a principal. But I have spent a surprising amount of time on their site, both in the Feed section and Browsing Stacks.

    The site is Stackshare.io, and the reason I think it is so innovative is what and who it is aimed at: Listing companies’ DevOps stack and offering advice on different parts of the DevOps stack.

    The Browse Stacks section is for presenting what other organizations are doing, so you can get good ideas for your own stack. But the developers of the site appear to have recognized the other useful aspect of this information: Matching organizations to prospective employees based on technologies. You can go look and see that Company X is using GitLab, for example, and that can then influence your job search.

    The Feed section is just a running discussion that uses categories to ask questions or offer insight and advice about decisions a given organization came to—so, “Chose X over Y” is actually a standard subheading for posts, as is “Need advice on Z” or “Recommends A”. It makes for great reading, and no doubt while reading through, you’ll have some advice to offer one of the “Looking for advice” posts.

    The Stackshare.io participants seem to range in size from startup to massive, and that is one of the things I hope they change as they grow—the options for looking at DevOps stacks are “Popular” and “Trending”. We all want more filters than that—organization size, number of apps, stuff like that—to help us zero in on environments that are similar to our own. My little company does not have the needs that Facebook does. And while it’s true that some startups use more tools in their toolchain than Facebook, you get the idea.

    Another issue I had with Stackshare.io’s site (that I fully understand, but still wish could be different) is forced registration/login to see some data. It’s not even particularly sensitive data—I know what ELK and Azure Data Services are, so putting the definition/description behind a registration page/login is kind of silly. But every free site needs data to pay the bills, and I suppose I’m glad it is info that’s also available elsewhere that is behind a reg wall.

    The company offers APIs for integration to your site/tool and private company instances of StackShare to help you manage one of my other gripes—the five (or fifty!) different DevOps stacks many organizations have allowed to develop in-house.

    So if you are job hunting, Stackshare.io can help you find companies doing what you would like to do or know you’re good at. If you are an organization trying to improve or set up a new toolchain (which is how I found the site), it has a lot of information to digest, though not all of it is easily accessible at this point. Either way, keep kicking it and keep an eye out for tools that do the job, no matter where you are looking.