devopsy.kinsta.cloud

Tag: cloud-native

  • RecruitOps, A Better Way To Fill Technical Roles

    RecruitOps, A Better Way To Fill Technical Roles

    Today at MediaOps, we are really excited to announce the launch of RecruitOps, a new and exciting way for companies to find the right candidates for hard-to-fill technical positions. It’s also a great place to find your next career stop.

    Sitting at the nexus of a worldwide audience of the biggest DevOps, cloud-native and cyber talent pool in the world—and a destination where organizations ranging from startups to enterprises come to stay relevant—devopsy.kinsta.cloud and other MediaOps destinations provide the perfect partner for this mission.

    The Usual Suspects Don’t Work

    For the last three or four years, I’ve been receiving multiple calls every week asking if we can help organizations find talent to fill their open reqs. Finding and hiring good DevOps, cloud-native and cyber talent is difficult and expensive and can be frustrating. Many companies have discovered that job boards and LinkedIn-type solutions create lots of noise, yielding slim pickings of viable candidates. Most candidates are misfits, either skills-wise or geographically.

    Also, traditional recruiters are not only expensive but they also operate in factory mode, often flooding your inbox with resumes of candidates they haven’t actually vetted first. There is a better way to do this—we think we have cracked the formula.

    By the same token, I receive messages on LinkedIn every day from people I don’t even know asking to help them find a DevOps or cyber job. The process of applying and being one of many résumés in a pile is not something they excel at navigating.

    Over the years we have tried job boards and relationships with large job fulfillment organizations. None of them were very successful. They were just not an effective way of matching our large audience of DevOps professionals with the many companies and organizations looking to find the right talent to fill their technical roles.

    RecruitOps: A Better Way

    My co-founder at MediaOps, Martin Logan, has lived this dilemma for years now. His full-time roles have been in building large engineering, product and DevOps teams in the online travel, retail, mortgage and gaming industries. He has tried every method you can think of.

    What Martin discovered was that the most effective method was to work with a small group of recruiters. These recruiters had to be very familiar with the technology and technical requirements of a requested position. They had to be able to talk the technical talk and understand it. More than that, though, they had to understand the culture and environment in which the candidate would work and what it would take to be successful there. This kind of information is best gained by developing a strong personal relationship with the hiring manager and the manager of the prospective technical position.

    That is the model we have built RecruitOps around. Our founding recruiters are people Martin has personally invested months and years in training. They know how to find the perfect fit for your technical roles. They know how to work with your organization and what it takes to be successful. They will not throw résumés at the wall to see what sticks.

    This is not a high-volume, résumé factory. At RecruitOps our recruiters are very familiar with the technical requirements that candidates must possess. They spend a lot of time with the hiring manager and position manager to understand what the perfect candidate must have skills-, temperament- and team fit-wise.

    Our RecruitOps recruiters then spend a lot of time getting to know the candidates before they send them to you. Combining devopsy.kinsta.cloud, Security Boulevard, Container Journal and even the DevOps Institute, our pool of talent for these technical jobs is deeper than just about anyone. We will find you the perfect fit guaranteed, or you don’t owe anything.

    No Risk to You

    Yes, that is another feature of RecruitOps: There is no risk on your end. If our candidate does not work out, you don’t owe anything. There is no money upfront—it’s a risk-free proposition all around. You literally have nothing to lose and great technical team members to gain.

    Does this sound like a better way for you? If so, head over to RecruitOps.com and get started today.

    Likewise, if you are looking for your next career move, head over to RecuitOps and put yourself on our radar. It is the first step in working with us to find you the perfect fit as well.

    In the Middle of a Pandemic?

    I know what some of you are saying: Wow, we are in the middle of a COVID-induced economic catastrophe. Isn’t this an odd time to start a recruiting business? You may be right. But we think this is the perfect time to start RecruitOps. Companies are realizing that there is actually some great talent available. Still hard to find, but more available than six months ago, perhaps.

    Also, organizations that are digitally transforming need help from technical people to make these transformation happen in a secure manner. We are betting smart organizations are adding great talent if they can get it because great talent is always in demand.

    Are you a smart organization looking to add great talent? Head on over to RecruitOps.com.

  • DevOps and Security in a Cloud-Native World

    DevOps and Security in a Cloud-Native World

    DevOps teams have naturally embraced microservices and modern application delivery workflows. But, they may get pushback from risk-averse leadership or feel slowed by security teams who struggle to keep pace. Development teams that play a greater role in guiding their organization’s cloud transformations will ultimately come out ahead.

    These are some of the takeaways from the largest and most globally expansive market research dataset on cloud-native security to date, the “State of Cloud Native Security Report 2020,” from Palo Alto Networks.

    Analyzing the data with a DevOps point of view may help your organization navigate its own transitions.

    Cloud Native Architectures and Security: What it Means for DevOps

    Organizations estimated that, on average, 46% of all workloads are already in the cloud and 95% of respondents expect that number to increase over the next 24 months. This likely means more resources and deployments for DevOps teams, but also means that security needs to meet the needs of these cloud workloads.

    Change is constant in cloud infrastructure

    Most survey respondents (80%) said their company’s cloud infrastructure is constantly evolving. This consistent change stems from companies experimenting and evaluating new cloud offerings, finding best practices and exploring new services.

    But this constant change impacts security teams and their tooling. Both in how they can continuously audit and protect cloud native applications today, as well as how they need to strategize on any anticipated change in the future—75% of respondents worried that cloud threats already outpace security.

    Multi-cloud is the industry standard

    DevOps teams have more options than ever before for running cloud-native apps. Nearly every organization surveyed—90%—confirmed they use more than one cloud platform. And respondents are using a combination of compute architectures: VMs account for 30% of workloads on average, with containers at 24%, CaaS at 21% and PaaS at 22%.

    As DevOps teams take advantage of increasing platform/compute permutations, security teams need both wider and deeper visibility across cloud infrastructure. For some security teams, this has meant more tooling—57% of teams reported using more than five security tools and some up to 11 or more—which may mean a proliferation of workflows, policy engines and dashboards.

    DevOps and security aren’t concerned with any single threat

    They have many that they prioritize differently. When asked for the No. 1 threat, no single answer stood out. Instead, 10 ranked about equally in frequency:

    • Data exposure (13.2%)
    • Malware (12.8%)
    • Application vulnerabilities (10.9%)
    • Weak and broken authentication (10%)
    • Insider threats (9.7%)
    • Credential leakage (9.1%)
    • Insecure APIs (9%)
    • Infrastructure misconfigurations (9%)
    • Application misconfigurations (8.7%)
    • Over-permissioned access and misconfigurations (7.7%)

    This means that DevOps and security teams may sometimes clash about what needs to be the highest priority and how to ensure they are meeting a high level of security.

    While many organizations feel that the diversity of cloud and the speed at which it changes can cause gaps in security, it also suggests there are ways to successfully minimize risks.

    Embedding Security Across the Application Life Cycle

    The survey analyzed the types of actions companies take in their cloud security, then created a ranking based on responses. (Details are available in the report.) Companies with the highest-level preparedness ranking were found to have many of the same habits.

    Many highly prepared organizations (45%) embed security into their DevOps processes and almost as many (41%) integrate security in at least four stages of the development life cycle.

    In addition to shifting security left, these organizations automate many security practices such as configuration monitoring and vulnerability scanning/management, eventually implementing guardrails or quality gates into their regular workflows.

    DevOps teams should work with leadership and security to identify consolidated platforms that can scale to continuously monitor configurations and protect the continuum of compute options discussed above. These types of platforms that can integrate security across the development life cycle are beginning to gain more attention and are becoming increasingly practical solutions.

    Next Steps

    The survey data makes clear that the cloud will continue to evolve as it matures, and it will remain multi-everything. It also suggests there are things DevOps teams can do to help set the model for how cloud is adopted in their organization.

    Security and development teams will need to increase collaboration to identify threats and controls. By shifting left and inserting security to the earliest possible point in the development process, using platforms that integrate across the life cycle, threats or vulnerabilities can be anticipated and their impact reduced.

  • Should I Stay or Should I Go? A Cloudy Decision

    Should I Stay or Should I Go? A Cloudy Decision

    If you’ve been operating in the cloud for some time now, chances are your business has changed since you first made that move and particularly during the current climate. Has your cloud usage grown considerably — and your OpEx costs? Is that just the cost of doing business in the cloud?

    It doesn’t have to be. Here’s how you can rationalize your infrastructure and determine if there are cloud expenses you can reclaim and even if it makes sense to move some of your cloud deployments into colocation.

    The rush to the public cloud has now slowed as organizations realized that it is not a one-size-fits-all solution. The main issue is the lack of deep visibility into the performance of applications provided by the host. Our own research has recently revealed that 32% of public cloud resources are currently under-utilized, and without proper direction and guidance, this will remain the case. What is needed is real-time data and intelligent recommendations to lower costs and assure performance.

    In order to optimize cloud resources, a third-party AIOps based resource is needed. This will provide an independent and granular view of how applications are using capacity and if it is right-sized. In addition, it will monitor the performance of the applications in real-time and provide metrics and analytics to eliminate bottlenecks. The allocated capacity can also be monitored to ensure an accurate match to workload requirements via real-time performance data.

    Although the major hosts provide cost optimization tools, these are not very accurate. Analysis of billing and how it matches capacity over time — as well as in real-time — is what is needed for the cloud to remain a vital part in IT infrastructure. Armed with this information you can plan capacity purchases and discover wasted spend. By using a single platform for cloud management, you can monitor your infrastructure, plan capacity and eliminate performance risks. Performance bottlenecks can be predicted before they affect clients and SLAs with multi-conditional alerting powered by advanced anomaly detection.

    Cloud solutions are not only publicly provided by the likes of AWS and Azure. Colocation is also a strong option where your applications are managed on your behalf by a system integrator. This is increasingly becoming a stronger option for more business-critical applications. But to determine which is best for you, you need to start with the facts. 

    The cloud promises IT organizations unprecedented value in the form of business agility, faster innovation, superior scalability and, most importantly, cost savings. For many organizations, it is at the core of their IT digital transformation strategy. It is a disruptive force that requires application workload behavior knowledge, careful planning and collaboration from well-informed, trusted advisors.

    As a first step, enterprises frequently target a subset of their less critical on-premises applications for migration to the public cloud. Typically, organizations will take one of two paths to the cloud:

    1. Going Cloud Native. Rewrite your application to use resources offered by a cloud provider.
    2. Lift and Shift. Very minimal or zero code changes to the application. Largely, just replicate the application in the cloud.

    The faster time-to-production choice is to lift and shift the targeted applications to a cloud service provider’s Infrastructure as a Service (IaaS). In the lift and shift option, the advantage is a reduction in the cost incurred in the physical infrastructure such as hardware, floor space, cooling, security, etc., and the management of that infrastructure. Savings will differ depending on your unique computing resource needs, workload refactoring and business models.

    Even in its simplest form, IaaS migrations must be carefully planned requiring answers to some fundamental questions:

    1. Will my application perform as expected in a public cloud? (Application Fitness)
    2. How much will it cost to run my applications in a public cloud? (OpEx)
    3. Which cloud service provider is the best choice for my applications? (Cost and Fit)

    IT managers need answers to these questions before the actual migration is performed. As most internal IT organizations don’t have deep cloud expertise, the question is: Who can you trust to provide you with the answers and help you make better business decisions?

    As technology and the cloud stands to play an ever-increasing role throughout organizations, ensuring that you’re adopting the right type of infrastructure specifically for your business has never been more vital for continued success. Choosing a service that provides the answers to your key questions, before the actual migration takes place and prepares you with vital insights into your applications and workloads targeted for cloud migration, has to be an important part of the decision-making process.

    As organizations continue to battle the COVID-19 storm, understanding the product that will overhaul your IT infrastructure, before you fully buy into it, is going to provide the confidence and assurance you need to make that decision a little less cloudy.

  • AppDynamics Survey Sees Rush to Digital Transformation

    AppDynamics Survey Sees Rush to Digital Transformation

    A survey of 1,000 IT professionals in organizations with annual revenue of at least $500 million conducted by AppDynamics, a unit of Cisco Systems, finds nearly three-quarters (74%) report digital transformation projects which typically would take more than a year to be approved are now being signed off on in a matter of weeks.

    The research also finds 95% of respondents changed their technology priorities during the pandemic, with 88% identifying digital customer experience as being a priority now.

    In addition, some 71% said some digital transformation projects have been implemented within weeks versus the months or years it would have taken to implement a similar initiative before the pandemic. At the same time, 66% of respondents noted the pandemic has exposed weaknesses in their digital strategies, creating an urgent need to accelerate initiatives.

    Not surprisingly, the survey also finds 81% of respondents said the pandemic has created the biggest technology pressure their organization has ever experienced, with 61% under more pressure at work than ever before. Almost two-thirds (64%) said they are now being asked to perform tasks and activities they have never done before.

    Despite the enormous pressure technologists are facing, 87% said this period of time is an opportunity for technology professionals to show their value to the business. In fact, 80% of survey respondents report that the response of their IT teams to the pandemic has positively changed the perception of IT within their organizations.

    The survey specifically identifies managing spikes in website traffic (81%), lack of unified visibility and insight into the performance of the technology stack and its impact on customers (80%) and managing mean time to resolution (MTTR) with a remote IT department (70%) as major challenges.

    IT teams during this time need clear goals and objectives (90%), real-time data at the point of need (89%), autonomy and accountability (88%) and the freedom to experiment and take risks (87%), the survey finds.

    Angie Mistretta, chief marketing officer at AppDynamics, said the survey mirrored an earlier AppDynamics report that tracked a rise in the use of search terms such as “digital experience monitoring” and “application performance management (APM).”

    In general, Mistretta said it’s also apparent the rate at which application workloads are moving into the cloud is accelerating as organizations look to deploy more resilient applications based on cloud-native technologies such as Kubernetes that are designed from the ground up to access remotely.

    It may take time for IT organizations to master cloud-native platforms to deploy microservices-based applications. As such, the number of monolithic applications being lifted and shifted into the cloud remains considerable. Once those applications are shifted, many IT teams will only then start to modernize those applications.

    Naturally, AppDynamics is betting many more organizations will require access to an APM platform to navigate this brave new world of legacy and emerging digital business applications in the cloud. The challenge for IT teams, however, is there have never been so many APM options available.

  • Cloud-Native Security and Performance: Two Sides of the Same Coin

    Cloud-Native Security and Performance: Two Sides of the Same Coin

    You’re running Kubernetes in a production environment, and you need to apply a patch — perhaps to a commercial application, an open source component or even a container image. How long should it take to implement that patch in production? Thirty days? One day? One hour?

    Remember, cloud-native environments are supposed to respond to change in real-time. Such a response isn’t simply scaling up or down as needed. It’s also essential to respond to security threats, and performance issues, as close to real-time as possible.

    Containers, and the microservices they support, are also ephemeral. They can live for five minutes or even less, and yet unpatched microservices are just as dangerous as more permanent code.

    Patching must also fit within your application lifecycle. Teams with a mature DevOps process typically release code weekly, daily or even hourly. Their ability to apply the patch and roll to production quickly, significantly reduces their security risk. Are your operators up to the task?

    Poor Security Management Becomes a Performance Problem

    The connections between security and performance go well beyond cloud-native environments. Denial-of-service (DoS) attacks obviously target a site’s performance, as do cryptojacking and to a lesser extent, ransomware attacks.

    In many cases, performance monitoring gives an organization its first indication that such an attack is underway. However, monitoring isn’t just for recognizing attacks in progress. It also plays an important role in the prevention of attacks as well — especially in cloud-native environments.

    To understand this point, think about how organizations have traditionally handled patch management, especially to software infrastructure: A vendor (or open source project) releases a patch. The enterprise applies the patch in a test environment that resembles production somewhat. After running a range of integration tests over the course of days or even weeks, the ops team may be ready to deploy the patch into production. 

    Another likely scenario: The ops team may collect several patches to different pieces of software, hoping to test and deploy them all at once. In the meantime, more time goes by, giving attackers even more opportunity for mischief.

    The reason that applying patches in an enterprise production environment takes so long is because IT leadership perceives that patch management is a high-risk activity. Patches may make a piece of software behave poorly or not at all — and the complex interdependencies among both applications and infrastructure components compound the risk of failure unpredictably.

    Cloud-Native Computing Changes the Equation

    Cloud-native computing extends cloud best practices such as scalability and resilience to the entire enterprise IT landscape, providing a new paradigm for computing across hybrid IT environments that leverage virtualization, containers and serverless computing as appropriate.

    At the center of the cloud-native movement is the open source container orchestration platform, Kubernetes. Kubernetes requires and reinforces a cloud-native architectural approach that decomposes applications into containerized microservices. 

    Deploying, managing and operating microservice-based workloads at scale becomes the central challenge for Kubernetes, and for cloud-native infrastructure in general.

    To manage patches, organizations must follow cloud-native principles. Monolithic, “test everything for weeks” approaches simply do not align with the dynamic, ephemeral nature of cloud-native software.

    Just as application developers use canary testing for features they are rolling out, canary testing infrastructure updates largely supplants testing in the full-blown test environment. 

    Testing patches (or updates) become an ongoing, largely automated process of trying new configurations in limited production environments, analyzing the resulting performance and rolling back changes if necessary.

    Operators can now test patches (or new releases) more quickly in production, in a way that ideally minimizes the impact on the applications that end-users interact with.

    How, then, should operators manage such canary environments? By monitoring the performance of the software under test.

    The Convergence of Security and Performance Monitoring

    Unpatched software is the leading source of vulnerabilities in the enterprise IT landscape, and managing patches in dynamic environments requires performance monitoring.

    Add patch management to other performance-related cyberthreats, such as denial of service, ransomware and cryptomining, and it’s clear that security and performance monitoring are two parts of a broad spectrum of IT operations management (ITOM) capabilities.

    In cloud-native infrastructure, ITOM doesn’t stop at monitoring. Instead, operators require observability tools that monitor logs, traces and metrics across the entire infrastructure, in addition to providing tools that operators can use to mitigate and prevent problems with the infrastructure.

    In other words, where monitoring is a passive, “watch the dashboard” activity, observability goes the extra mile, promoting an active, “understand and fix the problem” mentality.

    It doesn’t really matter if those problems are performance or security-related — in many cases, there’s no distinction. Today’s operators must work with tools that bring the two together into a full-fledged security, compliance and monitoring solution.

    The Intellyx Take

    Some analysts argue that IT infrastructure has followed a natural progression from on-premises servers to virtualization to cloud computing to containers. However, there is a fatal flaw in this argument.

    The first three environments in this sequence follow a clear pattern, as virtual machines work much the same as physical servers, be they on-premises or in the cloud. As a result, coding applications remained largely unchanged as enterprises worked their way along this progression to the cloud.

    Containers, however, are fundamentally different — especially once you place them into Kubernetes and the cloud-native context overall. With cloud-native computing, it’s essential to rethink the nature of the application from the ground up. Cloud-native computing is, in fact, an entirely new paradigm for enterprise IT.

    It’s no wonder, therefore, that core operational activities like security and performance monitoring have a new role in the cloud-native world. Indeed, security and performance are every bit as important as before, but today, we must deal with both at once in the context of a dynamic, ephemeral application landscape.

    Only within this context does it become clear what cloud-native vendors like Sysdig are offering. The world of IT infrastructure is changing, and with it the world of enterprise application development and deployment. Security and performance are as important as ever. Don’t let them fall through the cracks.

  • How to Secure the Intangible — Cloud Native Security in the New Age

    How to Secure the Intangible — Cloud Native Security in the New Age

    People don’t want to buy a quarter-inch drill. They want a quarter-inch hole.

    Companies aren’t interested in managing IT; they’re more interested in results. They want to deliver software quickly and focus on their core product or service. This is where the concept of cloud native computing comes in—and why securing it has become critical. 

    Traditionally, companies had many servers and resources. Today we’re moving toward a simpler reality. Developers are focusing on what’s needed to deploy business logic, regardless of what it’s deployed on. That’s why it’s particularly appealing to move to software without the server and the added complex management of IT overhead. 

    If a company can push its offerings without hardware, patch management, storage and so forth, and it can do it more affordably and faster, it’s a great win. 

    The Paradigm Change

    2012 was the golden age of IT, where admins ruled the world and developers got in line. Moving from that era to 2016, we come to the age of the cloud, where developers were kings.

    For many years, the IT department led—and perhaps stifled—innovation within organizations. Developers’ paths for innovation were limited to the area which they had control, i.e., the application layer. Anything beyond that was the IT department’s call. This included hosting, load balancing, database management and whether to adopt virtualization or advanced networking technologies.

    With the emergence of NFV and cloud computing, that changed. There has been a continuous erosion of the abstraction layers that developers were faced with in the past. In 2020, developers are the masters of their own destiny, pushing their organization toward innovation. All of this is possible not only due to virtualization and cloud computing, but also to the relative simplicity of a developer setting up a full application stack on their own laptop.

    In many organizations, the CTO focus has moved from an infrastructure orientation to an application focus. Developers are the new golden children of these organizations. They hold the keys to increasing company profits.

    What Cloud Native Brings to the Table

    There are many numbers being thrown around about the efficiency of cloud native. Whether it’s 300% reduction in deployment time or a mere 30%, the reality is that the time savings are huge. Many developers will never see a traditional data center again in their lives. In fact, new applications are developed as microservices or at the very least as containers, simply because they’re faster.

    There’s no going back. This new approach enables developers to invest in scalable solutions without making companies preallocate unnecessarily large sums of money. Both applications and infrastructure can scale up or down quickly, using the right amount of resources to provide the best service. 

    Businesses that are seasonal or peak-oriented gain a lot from the movement to cloud native architecture. Users also stand to gain from the move, as they receive the best service possible, without downtime. Everyone comes out on top.

    A Look at the Future

    This movement to broader use of cloud native architectures is a trend that will continue to grow over time.

    By 2025, VMs and bare metal will be as anachronistic as mainframe and token ring networks are today. In fact, most medium-to-large organizations already have some kind of a migration project from VMs to containers in progress. Many developers don’t need to spin up VMs anymore, since they can have a whole application stack running on their laptop using containers. When they are done, they simply lift and shift it to staging and production environments.

    In addition, on-premises and cloud environments are becoming a single entity rather than two separate infrastructures. People used to think that the entire data center was going to move to managed clouds for economical reasons. Today, however, most deployments are becoming hybrid. Organizations are opting to keep some of their on-prem systems (mostly legacy applications that cannot be easily moved to the cloud). IT administrators are starting to think about the deployment in the cloud as an extension of the on-prem data center rather than a separate network that needs to be managed.

    This trend will most likely continue, making it all the more important to understand the changing expectations around how to secure the hybrid network environment. The rate of change for cloud native environments is monumentally faster than on-prem, initiating code in milliseconds.

    Most legacy solutions weren’t built to cope with ephemeral networks and compute entities that go up and down within seconds, one million times a day. So, what’s the best way to future-proof risk management in this ever-changing environment? There is no singular answer, but in general prevailing advice suggests you consider the long view, exploring the options best suited for your approach and then look at each through a one, three and five year lens. 

    Cloud Native Security

    When thinking about the future of security, the basics stay the same and the threat modeling concepts stay the same. However, there are a number of security issues to consider, including policies, permissions and authorizations. As networks are converging, the security tools are as well. Looking forward, only solutions that can provide a genuine single pane of glass to control your digital estate will have a real impact on security.

    When looking at solutions to help apply security to cloud native architectures, ask the following questions:

    • Can I improve visibility in my cloud service? Applications may be deployed over multiple cloud instances and on servers in different sites, and even different regions, making it more difficult to define clear security boundaries. The right tool can help you to understand the scope and layout of your cloud resources, particularly if it automatically discovers applications on your cloud deployment and maps the data flows between them, making it easy to understand applications that you have running in the cloud and how they interact with one another.
    • Can I achieve a single view of multiple environments? The tools used to apply security need to adapt to be able to control hybrid networks across on-prem and multicloud organizations. For example, if your architecture requires policies to be deployed to the edge, how is it managing convergence? Numerous network solutions are barely aware of layer 7 process level, let alone containers. 
    • Can I set and maintain policies across these environments? Consider how solutions address network policies and understand potential challenges from both a technical and procedural point of view. Securing application traffic within cloud native architectures or between applications and external networks is a good start, but in the cloud, it’s necessary to implement micro-segmentation so you can define policies at the application level. By defining which applications are allowed to interact and the types of interactions that are permitted at a granular level, it’s possible to provide the level of security necessary for applications operating in the cloud. Look for tools that provide automatic policy recommendations that can be effectively applied on any cloud infrastructure, streamlining your organization’s security policy for deployments.
    • Can I future proof my cloud native security posture? When planning your future roadmap, think about what your network is going to look like. What type of workloads and network constructs are going to be used? Make sure the security vendors you select provide full coverage for your roadmap.

    When implemented correctly, modern micro-segmentation techniques can offer a simple way to secure a cloud native environment, including solving the unique challenges of containers and providing the ability to create dynamic application policies down to process level. Look for tools that provide a single view and foundational visibility, automatically discovering all network flows and dependencies. This allows your business to take advantage of the best of serverless computing without increasing risk or complexity for security.

  • Despite Downturn, Enterprise IT Budgets Remain Intact

    Despite Downturn, Enterprise IT Budgets Remain Intact

    A survey of 137 IT operations leaders at companies in the U.S with at least 500 employees and an annual IT budget in excess of $5 million finds a surprising amount of resiliency at the beginning of the COVID-19 pandemic.

    Conducted April 1 by OpsRamp, a provider of IT operations tools, the survey finds more than half of the survey respondents (58%) said they expect to either significantly or moderately increase their annual technology budgets, while 38% plan to either significantly or moderately reduce their technology spending.

    The survey also finds 73% of respondents expect to either accelerate or maintain digital transformation initiatives and projects.

    Bhanu Singh, senior vice president of engineering and DevOps for OpsRamp, said that at least for now among larger enterprises, digital business initiatives are being accelerated as organizations recraft their business continuity plans. With most customers and employees working from home, the need for applications that digitize business processes has become more critical, especially since no one knows for sure when the COVID-19 pandemic might subside or whether there will be another one, he said.

    Many of those projects will rely on cloud-native technologies that make it easier for organizations to scale IT resources up and down, added Singh, noting organizations are quickly discovering that monolithic applications even when they are deployed on a public cloud are not as flexible as they now require.

    Specifically, the survey finds IT leaders are investing heavily in AIOps (69%), information security and compliance (62%), self-service platforms (60%), cloud-native observability (51%), network performance monitoring and diagnostics (51%), big data analytics (46%) and cloud infrastructure (45%).

    IT leaders are also planning to drive technology vendor consolidation (59%) to reduce costs and rely more on third-party managed service providers (58%).

    In terms of hiring, IT financial analysts (68%), cloud architects (53%), DevOps engineers (50%) and data scientists (47%) top the list of priorities.

    Of course, as the impact of the COVID-19 pandemic on the global economy becomes more apparent it is too early to say what the impact on IT budgets will be. Industry analysts Gartner and International Data Corp. (IDC) are forecasting a relatively small decline in IT spending of about 5% for the year once the economy begins to recover in the second half. However, it’s clear that certain vertical industry segments, such as travel and hospitality, might have a much longer way to go than, say, healthcare companies.

    In addition, it’s likely that much smaller companies than those surveyed by OpsRamp may find it more challenging to restart operations after being forced to lay most of their employees in some cases.

    Whatever the timing, the one probable thing is many of the IT trends that were just beginning to gain traction are likely to see accelerated adoption once the economy recovers. There will be a natural tendency to limit the adoption of new platforms and processes in the short term. However, now that it’s clear existing platforms and processes are not especially flexible it’s only a matter of time now before most of them one way or will be replaced or at the very least completely modernized.

  • DevOps Chats: DevSecOps and OpenShift, with Red Hat

    DevOps Chats: DevSecOps and OpenShift, with Red Hat

    In this DevOps Chats, we had a talk with Kirsten Newcomer, senior principal product manager at Red Hat. It is a great discussion on the state of DevSecOps and how the Red Hat OpenShift team is trying to make it easier for developers, DevOps and cyber folks to work together to create more secure applications.

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

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, Container Journal, Security Boulevard—you’re listening to another DevOps Chat. Welcome, and I’d like to welcome to our DevOps Chat Kirsten Newcomer of Red Hat. Kirsten, welcome.

    Kirsten Newcomer: Thank you, Alan. Great to be here. So, I’m Kirsten Newcomer as you said, Red Hat. My focus at Red Hat is DevSecOps for cloud-native applications, been working at Red Hat for about four years now. It’s really kind of fun. I’ve managed to leverage kind of my—all sorts of different elements of my background over the years. I spent time at Rational Software, nine years, working on developer tools.

    Shimel: Sure.

    Newcomer: Yeah. Spent some time with BMC BladeLogic on the operations side of the world, seven years at Black Duck Software focusing on solutions that help companies manage vulnerabilities in open source software, and that led to the move to Red Hat where I get to focus on OpenShift security and DevSecOps and sort of everything comes together. So, DevOps—

    Shimel: It really does.

    Newcomer: Yeah.

    Shimel: I mean, following your career, I think I know just about all of those companies intimately and know a lot of people—I’m sure we even have a lot of people in common that we’ve worked with.

    Newcomer: I bet we do.

    Shimel: It’s funny. So, you were at Rational, left Rational only to return to IBM Rational.

    Newcomer: I know! [Laughter] That is true.

    Shimel: You know, it’s the circle of life right there, man. [Laughter]

    Newcomer: It is the circle of life, yep.

    Shimel: Welcome. So, Kirsten, look, DevSecOps is of course something near and dear to us. We put on every year at the RSA conference our DevSecOps Days or DevOps Connect/DevSecOps Days.

    Newcomer: Uh-huh.

    Shimel: We actually have the virtual event of that live on Thursday, I think it’s the 26th, March 26th.

    Newcomer: Nice.

    Shimel: So, you know, it’s something, quite frankly, this whole security thing is the reason I got into DevOps is, I thought—what a great opportunity for security to cure a lot of original sin.

    Newcomer: Absolutely. [Laughter]

    Shimel: But anyway, you know, when we look at the DevSecOps and the DevOps world, Kirsten, you can’t help—you must take notice of the impact that Kubernetes and the whole cloud-native kind of movement has had on this.

    Newcomer: Okay.

    Shimel: And a great—

    Newcomer: Absolutely, no—big changes, yeah.

    Shimel: And, you know—and it’s really at the core of so much of what is being done right now from an infrastructure point of view. And oftentimes, I don’t know if people—like everything else, right? I remember when the cloud came out and we moved from client-server and all this. Security, there’s always that lag, right, where, “Oh, yeah, we gotta do security with this.”

    Newcomer: Yep.

    Shimel: And we had a little bit of that with Kubernetes, I think, where—

    Newcomer: No, I think that’s fair.

    Shimel: Yeah? You know, people were rushing to do Kubernetes and experiment with it, deploy it, and then someone started saying, “Wait a second, what about security, here? What about compliance? What about this or that?”

    Newcomer: Yeah.

    Shimel: And now, I will tell you, and I’m interested in your opinion—I thought the lag time was much shorter this time than what we’ve seen in the past.

    Newcomer: Oh, I absolutely think so. And I think it’s really interesting. A couple of things that I’ve observed. One is that I really think containers and Kubernetes have created a terrific opportunity to shift security left, and I’ll kinda be more explicit about that in a couple ways. But I, in fact, have worked with a chief of cyber defense in the public sector who believes and evangelizes that containers improve security, and I’ve stolen his line, because I just actually think that that’s really valid.

    Because of the changes in the model, with the OS dependencies and the run time, everything’s kinda packaged together and you have that immutable container image that you’re always deploying from, you really can manage things in a new way and not every team is ready for this, and not every team, not every security vendor is ready for this, either.

    So, I think the opportunity has been twofold. One is to kind of adjust the thinking about security so that it no longer becomes something that happens at the end, but that’s still a process, that’s still a lot of work. And the other thing is, the security tooling space itself has historically been pretty siloed, right? There’s been, you know, the OS layer security, the network layer, there’s been kinda—you know, my SIEM and my SOC that I’m working with, and my cert management and my vaults.

    And none of them really were designed to work with the level of automation that Kubernetes and containers enable, which led to this really interesting opening for smaller companies, a lot of startups that now have been around for a little while, actually, to start breaking down those silos and delivering security capabilities in a new way that kind of really do fit the DevSecOps model, because you get kinda one vendor bringing a set of capabilities that ranges from CI/CD integration to run time security to network security, really fascinating space to see how it’s been evolving.

    Shimel: It really has. The other thing that I will tell you, Kirsten, that I was again encouraged by was when I first started seeing people talk about security through containers and Kubernetes, it really was like—let me scan your container for vulnerabilities, right?

    Newcomer:  Yeah. [Laughter]

    Shimel: And I’m thinking to myself—I don’t care whether my code’s in a container or in a hypervisor or on bare metal. A vulnerability scan is a vulnerability scan. There’s gotta be more to this than just a more vulnerability scan kind of a thing.

    Newcomer: Absolutely. And that’s, I think, where, as you mentioned earlier, that, you know, Kubernetes really has come a long way in that space. So, there are things like, if we think about—so, absolutely. Vulnerability scans are fundamental and kinda, people always understood those. They tended—historically, they’ve happened a little too late in the life cycle, making challenges for the AppDev team and such.

    We’re seeing that shift left a lot, but then there’s all these other range of things that you should be doing and can be doing to build security into the platform. And so, when we saw pod security policies in Kubernetes, for example, that’s a way that the Kube admin can take advantage of the Linux features that enable container isolation at the Kubernetes layer and enforce things like ensure that a container doesn’t run with unnecessary privileges.

    Shimel: Sure.

    Newcomer:  And so, we are seeing more capabilities—now, that’s still beta, so the community still has some work to do there. But as you say, we’re seeing more emphasis and, you know, the open source Kubernetes security audit sponsored by the CNCF is a great example of that.

    Shimel: Oh, absolutely. And look, CNCF has done yeoman’s work here. They’ve really, really done a nice job with the whole Kubernetes project, specifically security.

    You know, but one of the reasons, like—we did a webinar yesterday for instance and it was on, you know, the different cloud providers versions of Kubernetes and—

    Newcomer: Uh-huh.

    Shimel: [Cross talk] environments. And, you know—fantastic, we had 700 and something people sign up for this webinar.

    Newcomer: Great.

    Shimel: A lot of great questions, even on the YouTube afterwards, a lot of great questions. One of the things that became clear to me in listening to people talk is that—you know what? Just going to, whether it’s AWS or Azure or GCP or whatever and setting up my Kube environment may not be the best thing for me because I’d rather get one of the package distributions, if you will, or a more complete solution, of which Kubernetes is a piece, like an OpenShift, but some others were mentioned—Rancher and so forth.

    Newcomer: Sure.

    Shimel: But OpenShift was the most popular one mentioned. And I think one of the reasons is, people want to know that security has been kinda built into it.

    Newcomer: Yeah.

    Shimel: Beyond just the Kube release, whether it’s 1.4, 1.5, what have you, 1.6—you know, what else has been wrapped around that just K8—

    Newcomer: Yeah.

    Shimel: —to make it easier?

    Newcomer: Absolutely, and that’s been a big focus for us at Red Hat, really, from the beginning. You know, an enterprise solution—and this is a place where, so, we’ve talked about changes in the security tooling that needed to be made to adjust to the technology, but by and large, the principles still apply. You know, you still need audit logs, right? You still need, you know, to log data from the cluster itself. You need log data from the applications. You need monitoring tools. And so—and you need to think about host arrest security as well.

    And so, we’ve kind of really looked at the stack as kind of spanning all of those things, and we want to make it as easy as possible to manage that solution as a solution, right? And so, that if you—and plenty of folks do this, you know, and get value from it. But if you’re in a situation where you can afford to kind of do a DIY Kubernetes and add in a logging stack and add in kind of all the different pieces that you really need for the enterprise solution, then you have to maintain them each separately and you’re maintaining the host OS separately as well.

    And so, we’ve really focused recently, especially with OpenShift 4, on automating everything, which includes the host operating system. So, Rel CoreOS, Fedora CoreOS available as an open source project. It’s a container optimized operating system that we manage as part of the full platform. It makes it much easier to apply OS updates across your cluster. You can do that in a way that has zero downtime for your well-behaving apps. You can take a node out of service in the way you would, you know, that Kubernetes manages it. Update that with a patch to OpenShift or its components or the operating system itself, put it back in service.

    And so, kind of a combination of looking at the whole stack holistically, what is an enterprise need in order to ensure that they have a secure environment, a stable environment, a highly available environment and making sure that we kind of leverage the terrific declarative and automation capabilities of Kubernetes kind of throughout the whole stack.

    Shimel: Absolutely. You know, I didn’t realize just really all of—you know, until you just said it, I never kinda put together all the pieces of what you guys are doing with that. It’s pretty amazing, isn’t it?

    Newcomer: It’s really cool. And one of the other fun things that we get to do is, we actually—so, back to, if we think about the host OS layer for a bit, right? If you need to scale your clusters, that means adding a new host and you’ve got the work involved to be sure that you deploy that infrastructure and that you secure that infrastructure according to your standards and then you put Kubernetes on top of it and add it to the cluster and you’re ready to put workloads on it.

    And we’re using the concept of Kubernetes operators to automate the components of OpenShift, including the host OS. So, we have a machine config operator, so if you’re deploying OpenShift in a cloud where you can automate the addition of infrastructure easily, you can use the machine config operator and the declarative nature of Kubernetes, right? It’s a container optimized OS, it’s delivered primarily as container images, the user space is read-only, you’ve got that declaration of what a host should look like and you can just use the machine config operator to spin up new hosts and add them to your cluster.

    Shimel: Excellent. You know, we would be derelict in our duties, I guess, if we didn’t mention the whole COVID-19 and how that’s affecting things.

    Newcomer: Fair enough, yes.

    Shimel: In my mind—so, first of all, I don’t think a lot of what we’re seeing right now and its effects are necessarily three-week or six-week or, you know, a lot of this stuff is gonna stick.

    Newcomer:  Yeah.

    Shimel: I think one of the things that are gonna stick are, people are gonna want more automation, right?

    Newcomer: Absolutely.

    Shimel: In their deployments, in their operations, in their infrastructure.

    Newcomer: Yep.

    Shimel: And automation, from a security point of view, is kind of a double-edged sword, right? At least we, from—when things are automated from a security point of view, we think we know exactly what’s gonna happen, and so we can plan around that. On the other hand, security people tend to get a little fritzy, you know, when things come out of our cold, dead hands, here.

    Newcomer: Yeah.

    Shimel: What do you think? How—what do you think?

    Newcomer: I know; I agree with you. And I think one of the things that, one of the ways that Kubernetes is kinda pushing the boundaries with security teams. And I talk to a lot of different security teams over time. So, it’s kinda like—you know, they’re a little bit more comfortable with the idea of DevOps for the application layer at this point, right? For those containerized apps that are gonna be deployed, it’s like—okay, they kinda have an idea of, “Yep, security static analysis tools, integrated vulnerability scanners integrated.” There’s some cool new stuff coming out that I’m seeing on the market, they’re tools that are starting to evaluate the configs and the Dockerfiles, too, that’s really great.

    But—and then as we continue to move into the ops space, right, with Kubernetes and the SDN, which is required for any Kubernetes cluster, and now we have service mesh added into the mix, or Istio for microservice based communications. The network security teams are uncomfortable with who’s gonna manage network policies at the Kubernetes layer and now, I’ve got service mesh or Istio policies as well, and who’s responsible for those?

    And in the end, it’s really about visibility. So, if we circle back to automation, we’re really looking at infrastructure as code, you know, GitHub’s model that applies again to the Kubernetes layer, to the configuration of the Kube cluster as well, and we need to put in place, you need the automation to get the best results, but you need to do it in a way that gives the security team visibility into the kinds of things they’re used to seeing.

    And so, I think this is another way where we’re starting to shift left in new ways, and I’m also seeing solutions that help automatically generate network policies based on evaluating an environment or an automatic generating service mesh policies based on evaluating the config for the apps.

    But all of that, you know, the network security guys aren’t necessarily gonna log into the cluster to look at that. So, how do they get the view they need to get, and how do they help the AppDev teams understand that whole risk management and their security perspective? And so, this is where it’s not just about tools, it’s about people and processes, right? And I think there’s so much richness here, but you’re absolutely right—we can’t do it without automation. And so, we’re gonna have to help these people become comfortable with this shift while ensuring that they get the visibility they need to know that things are being done in a way that meets their risk guidelines, their regulatory requirements, and the security posture they want.

    Shimel: So, to me, one of the fundamental things with DevSecOps, one of the fundamental shifts in DevSecOps is, first of all, security people recognizing that they’re not the only ones who care about security.

    Newcomer: Mm-hmm.

    Shimel: Believe it or not, the developers and the DevOps folks, they do care about security. They may not be security trained people, but they care about security.

    I think the second thing with that is, the developer people have to realize, and the DevOps teams have to realize that the security people aren’t there just to be the roadblock.

    Newcomer: Right.

    Shimel: And they aren’t always gonna be the people who say no.

    Newcomer: Right.

    Shimel: And what we’re—so, this has nothing to do with technology, per se. This is a people to people issue.

    Newcomer: Absolutely.

    Shimel: And I think we’re making real progress in that, and as a result, what we’re seeing is security people paying for and approving security tools that developers in DevOps teams are using—

    Newcomer: Yeah.

    Shimel: —on the Kubernetes platform—

    Newcomer: Yep.

    Shimel: —you know, because that’s kinda the platform of choice now, and that, to me, that’s what keeps me optimistic about this.

    Newcomer: Yeah. No, I’d agree, and also, when we think about the broader landscape, I mean, there’s, the security threats are just ever-evolving, ever-changing. And there aren’t enough security trained professionals to go round, right? There aren’t enough cybersecurity folks, et cetera.

    And so, we have to figure out, how do we help teams scale, and collaboration is the way to do that. And you’re right, I see the same thing you do, right, that the security team is approving those tools that are container native, Kube native tools that help to ensure. And in some ways, I don’t mean this in a negative way, but in some ways they kind of are pushed into that because they’re traditional tools that used to be used kinda at the back end of things aren’t effective in the container and Kubernetes world.

    And so, they really do have to go with this shift that we’re seeing in the vendor landscape, and it just opens up this terrific opportunity, though, for that collaboration and that shared knowledge which, you know, is an adjustment for people sometimes.

    Shimel: Yeah, agreed, agreed. Kirsten, when we first started, I said, you know, the time goes really quick, I’m only gonna keep you here 15 minutes—well, that was 21 minutes ago.

    Newcomer: [Laughter] Okay.

    Shimel: We—yeah, we did it. Alright. We’re gonna have to call a wrap on this one. Maybe we’ll have you come back another time and we—

    Newcomer: It’s a plan!

    Shimel: —can continue the conversation there, good?

    Newcomer: Great. It was great fun—thank you so much, Alan.

    Shimel: Thank you.

    Newcomer: Alright.

    Shimel: Kirsten Newcomer, Red Hat, our guest here. This is Alan Shimel for devopsy.kinsta.cloud, Container Journal and Security Boulevard. You’ve just listened to another DevOps Chat. Stay well, everyone.

    — Alan Shimel

  • Comparing Three Approaches to Multi-Cloud Security Management

    Comparing Three Approaches to Multi-Cloud Security Management

    Moving to a multi-cloud environment can bring many advantages, but it also brings huge challenges in managing both the everyday operations and security of multi-cloud infrastructures.

    To meet these challenges, several approaches to multi-cloud management have arisen. The most common can be roughly grouped into three categories: Cloud Management Platforms (CMPs), Infrastructure as Code (IaC) and cloud-native abstraction. The differences between these approaches reflect the differences between top-down and bottom-up cloud management, as each management process suits a different set of companies.

    In this article, we’ll take a look at all three approaches, explain what the advantages and disadvantages of each are and then explore whether new approaches to multi-cloud management are required.

    CMPs

    CMPs are the highest level approach to cloud management—the approach that is furthest away from the native code that your clouds run on. The rise of CMPs has come as the result of a simple observation: public cloud services are redundant and overlapping, and can therefore be managed through an abstraction layer that hides the complexities of what is happening at a cloud-native level.

    By using a CMP, admins do not need to understand the differences between AWS and Microsoft public clouds (for instance), but instead use a consistent interface to manage both.

    This has some huge advantages, primarily when it comes to improving cloud security. CMPs allow IT operations teams to implement a common security layer within multi-cloud environments, and apply the same identity and access management (IAM) processes across all the clouds they are working with. 

    This is particularly useful with cross-cutting applications that interfaces with multiple, critical portions of your cloud storage to help simplify, and which requires highly complex user access policies. This is ultimately one of many reasons why security breaches of cloud-based data are so rare, as 99% of businesses in the UK that rely on cloud-based software have never experienced a security breach. 

    IaC

    IaC is a second approach to multi-cloud management. This approach arose in response to utility computing and second-generation web frameworks, which gave rise to widespread scaling problems for small businesses.

    Administrators took a pragmatic approach: they modeled their multi-cloud infrastructures with code, and were therefore able to write management tools that operated in a similar way to standard software.

    IaC sits in between the other approaches on this list, and represents a compromise solution. It gives more fine-grained control over cloud management and security processes than a CMP, especially when used in conjunction with SaaS security vendors whose software can apply a consistent security layer to a software model of your cloud infrastructure. This is important because SaaS is growing rapidly in popularity, with 86% of organizations expected to have SaaS meeting the vast majority of their software needs within two years. 

    On the other hand, IaC requires a greater level of knowledge and vigilance than either CMP—or cloud-native approaches. If admins are knowledgeable enough to write code that can accurately (and reliably) model multi-cloud infrastructures, IaC can be a powerful way to improve DevOps security. These software models, however, will require constant monitoring to ensure that changes in the cloud-native layer do not introduce vulnerabilities into management tools.

    Finally, IaC can be significantly more efficient, when it comes to computing and network resources, than a CMP. Because IaC software runs closer to the cloud-native layer than (most) CMPs, it can execute common tasks much more quickly.

    Cloud-Native Abstraction

    The final approach to multi-cloud management is to manage your environment using only cloud-native tools. This approach has grown in popularity recently, as developers grew increasingly comfortable with working with containers and Kubernetes directly. Cloud storage providers have responded by offering increasingly complex tools designed to work directly on the cloud-native layer, and the storage provider you use should come with these tools.

    Cloud native application management has several advantages, and several disadvantages. The most obvious advantage is that cloud-native tools give admins a much greater level of control over their multi-cloud environments than the other approaches on this list. Because these tools run natively, they are also typically faster and more efficient than the other approaches we’ve mentioned above.

    On the other hand, saving computing time comes at the cost of increasing the workload for administrators. If you are working across a large number of clouds, managing each separately using each cloud’s native applications can quickly turn into a full-time job. In addition, managing multiple and complex access and usage policies at a cloud-native level can make it difficult for admins to keep on top of how their IAM processes are running, and increases the risk of mistakes. 

    Is It Time For a New Approach?

    All of the approaches above are a different solution to solve the same problem, namely the challenges caused by rapid adoption of multi-cloud technologies. Each, as we’ve seen, has a primary advantage when compared to the others. But in truth, none of the approaches above represents a completely adequate solution to managing security in multi-cloud environments.

    The choice of which approach to take must therefore be a pragmatic one. For companies who are blessed with the knowledge, talent and time to manage multi-cloud infrastructures at a cloud-native level, this is likely to be the best solution, especially at a time when cloud waste is booming. If you take this approach, however, you should also be aware that implementing it will require putting in place thorough and rigorous code auditing processes in order to ensure that any small IaC elements that run on top of cloud-native tools do not introduce common security vulnerabilities into your network.

    For small to medium size businesses, or those running hugely complex multi-cloud systems, CMPs will be a safer bet. The reduced efficiency of these services–both in terms of computing resources and capital investment–is likely to be more than made up for by the reduced load on the admins who spend their days working with them, and the reduction in the number of mistakes that are made.

    Ultimately, it’s apparent that a new approach to multi-cloud management is required. One that combines the flexibility and speed of cloud-native with the ease of CMPs. But at the moment, it’s difficult to ascertain what that will look like.

    — Gary Stevens

  • EP 3: Open Source and DevOps

    EP 3: Open Source and DevOps

    In the third episode of our DevOps Unbound streaming broadcast on TechStrong TV and devopsy.kinsta.cloud’s sister site Digital Anarchist, Alan Shimel is joined by Kevin Dunne of Tricentis, Tracy Miranda of CDF and Alon Girmonsky of UP9 to answer the question: Can we have DevOps without open source?

    The video is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript

    Alan Shimel: Hi everyone. Welcome to another episode of DevOps Unbound. DevOps Unbound is sponsored by Tricentis, so many thanks to them. But it’s our show here at MediaOps and we try to explore, you know, just some of the areas around DevOps and not just dev and ops but DevOps as a framework for the way things are being done, the way application and software is being made and deployed today, the way it’s being hosted, the way it’s being operated and maintained and observed, and so many other aspects of how we’re doing technology. 

    It airs every other week and this episode is episode number three of DevOps Unbound. Hope you’ve enjoyed the first two.

    With that let me introduce to our panel today. First of all, well, it may not be right or left on your screen, because so it makes no sense to tell you how it is on my screen, but let me first start off with my friend, Tracy Miranda. Tracy is the executive director of the Continuous Delivery Foundation, which is a Linux Foundation and a sister organization to Cloud Native Computing Foundation. Got that all out of the way. Tracy, welcome. 

    Tracy Miranda: Hi everybody and thanks for having me Alan. 

    Shimel: My pleasure to have you on Tracy.

    Joining Tracy and I today, I have Kevin Dunne, who has been on our TechStrong TV in the past. Kevin is with Tricentis and runs their open-source communities, as well as some of the open-source projects that are now under their management, some by acquisition over the years, some they’ve developed themselves. But Kevin, welcome to DevOps Unbound. 

    Kevin Dunne: Thank you, Alan. Happy to be on and glad you’re having us back with you again. 

    Shimel: That’s our pleasure. 

    Then last by not least is my friend, Alon Girmonsky. Alon is the CEO/founder of UP9, that’s U-P-9. He’s going to tell us about that when I ask everyone to introduce themselves here in a moment, but Alon was also the founder/CEO of BlazeMeter, a very well known open source or player in the open-source testing world acquired by CA, which of course became Broadcom. 

    So, today’s episode ladies and gentlemen is around DevOps, cloud native and open source more importantly, most importantly, and how important open source is to this whole DevOps movement and this whole — Someone today, I had someone from Deloitte Cloud on and I was doing an interview called it a “revolution” that we’re seeing, especially since COVID, right? IT has undergone a revolution of cloud transformation, digital transformation, acceleration and so much of it is made possible by open source. So that’s our subject today. 

    Before we hop into it I wanted to give each of you like 30 seconds, just in case our audience wanted more than the cursory kind of introductions I did. Why don’t we start with you Kevin? Give them who you are, your background and we’ll jump through all three of us from there. 

    Dunne: Yeah, that’s great. My name is Kevin Dunne. I’m with Tricentis as Alan mentioned. My main focus is on our open source and sort of community products. I’ve been with Tricentis for seven years. Prior to Tricentis I was at QASymphony, which merged with Tricentis about two years ago. So very passionate about open source, it’s been sort of a new area that Tricentis has been getting into. 

    There was a lot of work around Flood, which was built on top of JMeter and Gatling and now Tricentis has acquired TestProject which is built on top of Selenium and Appium and most recently SpecFlow which is an open source project based on cucumbers. 

    So I’m really excited to see how these tools are helping to kind of shape the Tricentis roadmap and sort of broaden the community in the open source supports, so very exciting projects going on so far. 

    Shimel: Alon, how about you?

    Alon Girmonsky: Hey everyone and Alan thanks for inviting me. I’m a big fan both of Tricentis and obviously the CD Foundation. Alon Girmonsky as you mentioned my current company UP9, which I have the privilege of being cofounder in, deals with microservices and cloud native in respect to testing. Testing is something that is becoming harder and harder to do, especially when you know you talk about service testing and API testing. So UP9 provides a solution for somewhat autonomous, mostly automatic you know service testing. 

    As you mentioned prior to that my previous company, BlazeMeter, was all about load testing and stress based on the open-source tool JMeter. You know I had the pleasure over the past 10 years to be involved in the open-source community and understand or at least try to understand what’s the place of open source and why is it so important specifically for developers. I’m very happy to have the opportunity to discuss this in this forum. 

    Shimel: Last, but not least Tracy how about you?

    Miranda: Tracy, I’m the executive director of the Continuous Delivery Foundation or CDF, which is an open-source foundation with the mission to improve the world’s capacity to deliver software with security and speed. The CDF is home to the open-source project Jenkins, JenkinsX, Tekton and Spinnaker. 

    Before that I was leading open-source community at CloudBees. In general I’m a 15-year veteran of open source, so I love all things open source, open innovation and building communities. 

    Shimel: Excellent. So folks, here’s my opening premise and we’ll let — it will be our jumping off point. 

    I also have a long involvement in the open source world. I first got involved in open-source security related projects 2002, 2001 and we were blessed in security to have some amazing open-source tools at our fingertips. Products like Snort, which was developed by Marty Roesch, who then started Sourcefire, acquired by Cisco, was the de facto standard for intrusion detection. The NMap and Nessus scanners, Renaud Deraison, who’s cofounder over at Tenable Network Security and Ron Gula, who started Tenable with Nessus. NMap has been out there. There were many others, ClamAV and so many commercial companies actually sprang up just by using that open-source software under the covers putting a UI on it and stuff. 

    So I’ve seen open source. I remember talking to CIOs and I remember speaking to you know a DOD agencies about their use of open source and they would tell me that they don’t have any open source, they don’t allow open source and then you would go look at what their developers were working on and it was all open source, you know it was Linux and everything else that they had, just didn’t bother telling them about. So I’ve seen open source become from a gorilla-type of operation in many environments, to the dominant form of software and software development today. 

    When I got into DevOps it became really apparent to me and this is my jumping-off point, we wouldn’t have DevOps without open source. I just don’t think — I think so much of what we can consider not only the tools of DevOps, so specific open-source projects, but the culture of DevOps, the collaboration, the sharing of knowledge of DevOps is based upon that open-source mindset, on the open-source culture that you couldn’t have DevOps without open source. 

    Tracy, you ran the open-source community of CloudBees first and only ED at CDF, part of Linux, what’s your feeling on that? Why don’t you kick us off? 

    Miranda: Yeah so definitely as a big fan of open source I’ve seen how it’s been really instrumental to DevOps. I think you know one of the things that open source does really well, like sometimes people focus just on the code, but it is really all about that collaboration, how people work together. I think at the heart of DevOps really what it’s trying to get at is building bridges, getting people to work together even if they are in slightly different spaces, whether you know it’s DevOps COPs who are trying to bring security practitioners closer to developers or ops people closer to developers. I think open source really captures that spirit of collaboration and that’s why it’s become almost synonymous with DevOps. 

    Shimel: Kevin, Alon, what do you think? 

    Dunne: Yeah, I mean I would definitely agree with that. I would say one other thing that you know of the many benefits of open source, right, is kind of just the transparency and visibility. I think you know a lot of companies were finding like DevOps in the CI/COVID process especially is kind of integral to business success, right? So a lot of companies are very hesitant to put a tool in place that is going to be that critical to their success unless they’re able to you know fully understand what it does, you know any limitations that it has, you know extended where needed and you know kind of have that ability to build on top of it as well.

    I think way too many companies kind of got burnt a bit by you know solutions that were completely closed source, didn’t allow customization and things like that. Then you know they kind of get stuck when you know something breaks. So they reach the limits and the vendor is not able to you know update that for them. So I think that was one of the big things about you know the whole Jenkins’ community, right, as you just see how many plug-ins and other you know ways people come up with of extending the tool that you just would never see from a closed-source product, right. So I think that’s been something as well as just kind of like the ability to have the transparency into how something works and be able to extend that to fit your own needs is pretty critical to DevOps success I think. 

    Shimel: Yeah, I, I agree. Alon, you more than I think even Tracy and Kevin I mean you built a business with a successful exit on an open-source kind of business model if you will. You know what’s your view on… Is, can, is it a chicken and egg? Can you have DevOps without open source?

    Girmonsky: I think if we go back even in more than a decade there was open source and there were commercial offerings, right? There was an inherent conflict between the two. 

    I think that if you fast forward for today it’s about product market fit. I think open source needs to be part of any product as long as it involves developers, maybe even more than developers, but developers as Kevin kind of mentioned we talked about transparency I think developers need to have control. They cannot rely on someone else to have a black box. So anything from transparency, having control, not having dependency. You know if you think about speed to market the more control you have your ability to change quickly you know the faster you can go.

    So what we’ve learned over you know the past decade the developers they need to have the open source not because it’s free. I think that’s the last aspect of open source. It was in the past it was free and a poor man’s solution. Today you want to have open source because you want to maintain control, visibility, transparency and reduce the dependency on other vendors. That’s kind of my key learnings you know from my experience. 

    Shimel: Yeah. I mean that reminds me of something I’ve always been taught and heard about open source and that is look with open source it’s free as in freedom and free as in beer, right? It doesn’t cost, it’s free as in beer, right, free beer for everyone. But really though that was a big driver, you’re right Alon that was a huge driver and remains a huge driver that people can just pick up this software and run with it. And if at some point they want to buy an enterprise license or an enterprise version or go to a vender that has a supported version they can pay for it, but they can use it for free today. But more importantly than that is the freedom as in freedom, right? In that it gives them the transparency, it gives them the ability to see exactly what it is they’re getting themselves into as Kevin pointed out. 

    But to me that’s almost turned the original problem on its face. Tracy you’ve been in these, in this open-source world longer, as long enough, right? In that originally that was also one of the big shortcomings of open source, right, is that everybody, everybody sees the source code, hackers or whoever will more easily exploit that source code or can break in or can see what’s going on. And whom am I going to call, Ghostbusters, right, for support and to fix this thing, right? 

    And so how can I as an enterprise you know based my business on open source? Is it reliable enough, secure enough, supportable enough? But yet we seem to have overcome that. One of the reasons I think, Tracy, is because of the advent of foundations like the CDF, right? So talk about that if you will a little bit. 

    Miranda: Yes, yeah, no absolutely. Like I think well first of all I want to make it clear like you can still have DevOps with a proprietary CI/CD stack and there’s plenty of offerings out there. But I think the key thing where open source plays a big role is it’s really in driving the innovation across the industry, making it so people can leverage it in different ways, combine it and get that interoperability to you know produce things that solve their problem. 

    And the way foundations have really helped is dealing with some of the issues or you know sometimes there have been misconceptions with open source, but sometimes they are genuine problems, which you know fall in the gaps of well maybe the developers on the projects want to focus on the code and there are other things we can do across multiple projects to help you know whether it’s focusing on security or focusing on building communities that are diverse. So open-source foundations have just added that extra layer to give the industry confidence that these are trusted projects that are being well sustained and people can rely on them to either build products or use in their own CI/CD stacks and really just kind of push, push things further I a good, positive direction for the whole industry. 

    Shimel: I’m going to comment or not disagree, but I wanted to distinguish and clarify something you said there Tracy and that is yes there are closed source or commercial or whatever you want to call it CI/CD solutions out there. But even they and we report on them at devopsy.kinsta.cloud right, even they rely on open-source integrations, open-source components. 

    I mean you look at Alon with what you’re doing with UP9, with UP9, with what you did in BlazeMeter. Kevin when he talked about the three or four different open-source kind of based tools that Tricentis is doing, they’re all based on open source. When you go under the covers they’re closed source but they’re based on open source, things like Selenium and these kinds of things. 

    So you know even in the CI/CD space and I’m not here to name names, but we know the closed source you know CI/CD players. I don’t think they’re product works well if you didn’t have an open source kind of framework that they plug into. I think it’s especially true in the testing world. I think Alon you’re living proof of that, right? Could you have had a BlazeMeter without having some of those great open source? Kevin all of the projects you mentioned are based on open source, right? Can you have any of them without open source? It’s a real you know … 

    And guys don’t wait for me to ask your name, feel free to jump in here. 

    Dunne: I think it’s a good point. It’s becoming more of the model like Alon was you know mentioning is it’s kind of you stand on the back of giants a lot of times, right? So I think you know you see a lot of the at least in the testing space, right, BlazeMeter, Sauce Labs, BrowswerStack, you know a lot of these bigger companies they’re succeeding by basically doing what you were talking about with the security tools 10, 20 years ago, right? 

    Take an open source community and kind of you know build something on top of that, right, that provides value, but still is kind of using this known currency of this open-source project. I think people like that because you know by the time they get to buying that commercial solution they’ve got a lot of confidence in the open-source components that have reached a you know critical kind of juncture where they’re bought into those tools enough that they’re willing to invest in something you know commercial to help support it and you’re solving real problems, right. 

    You mentioned you know free and open source being free, but you know everyone knows one of the big challenges with open source is just the amount of time that you have to invest a lot of times to customizing it, deploying it, you know patching it, upgrading it, dealing with security concerns. And so you know a lot of these vendors come in and they solve a real problem, but I think it is a little bit of a you can put the cart before the horse, right? 

    The people need to adopt the open-source tool, see that it works, feel the pain of you know what it’s like to manage it on their own and then you know usually graduate to these commercial solutions. I think when people come and try to present the commercial solution upfront without that open-source community you know it kind of fails because you haven’t proven the value yet, right? And it’s a big jump for people to make and that’s you know been a good thing in the market having open source. It’s kind of put the power in the hands of the users that you know users get to call the shots first and the user expects you’re going to give me some value in this open-source tool before you start to charge me an arm and a leg, right? 

    Miranda: I like the analogy, free as in free puppy, so we can have it, but you still have to take care of it, feed it, and keep it from pooping on the carpet. 

    Dunne: Exactly yeah. 

    Girmonsky: Yeah. 

    Dunne: And that takes a lot. 

    Shimel: Alon? 

    Girmonsky: I think I’ve learned a good concept a couple of years ago, kind of the open core concept. It wasn’t there ten years ago, but then you understand okay this is what, what we’ve been doing all along. The ability to open your core, the core of your platform, the core of your offerings. So you know your user will have more flexibility. Maybe the use case is a bit different than what you had in mind initially, right, by having an open core or an open-source project that you’re basing on, right, you allow the users to build their own use cases and then bring value that again the product market fit is in my view better than anything that has close and this is what you can do with it and that’s it. 

    Shimel: Agreed. So Tracy you know the CDF is a great model for the kinds of stuff we’re all three of us are talking about, right? You have in essence this four main properties or projects that CDF manages. Each one of them is closely tied to one or more commercial entities that solutions are based upon, right? But yet the community revolves around the CDF. By the way it’s the same thing in the CNCF, right, where you have Kubernetes and you have you know a lot of Kubernetes service providers that manage Kubernetes, but the community lives around CDF. 

    What are you seeing here? Like where is that handoff? Where is the you know passing the baton from that open-source user to the commercial entity? 

    Miranda: Yeah, no I think that’s a great question. What we see, well certainly what I’ve seen over the last 15 years is it’s an ever-changing line if you like. So when we talk about innovation you know we have these open-source projects and we don’t want people to be reinventing the wheel over and over again. Like take something like pipeline orchestration. You know when it gets to a point where that’s pretty ubiquitous then that’s a good thing to have as an open source you know kind of standardized in one project. 

    Then we can move up the stack into new innovations and vendors can lead that charge of take open-source projects and try to build things on top of that that add new things to the industry. As those become more and more ubiquitous then you know it probably eventually will get an open-source solution and then people will sort of move onto the next thing. 

    So I think it’s always kind of this tide as such where the more kind of proprietary things will test out the beating edge and where they can get value for using some things that haven’t been done and then open-source projects become like the infrastructure, the roads, and the bridges and things like that. 

    Shimel: Fair, guys any comment on that?

    Dunne: Yeah I think that’s true. It’s kind of tough though puts vendors in a tough position, right, where it’s like you know you have to – it really raises the bar, right on delivering innovation, right, because you know all of the… It’s kind of a commoditization, right, that you know things that have been in the market for 10, 20 years you know the market, the commercial market for those sort of erodes and you know it gets replaced by open-source tools. And so it’s always kind of playing that game of being the you know next hand-up on the baseball bat. 

    You know it’s just like your always – if you stop innovating there’s… I think that’s why you see you know the SAS model being really popular with a lot of these software companies is just they need to keep innovating, right, and you can’t just like you know expect to sell a tool, a licensed tool and you know have a customer use that for ten years and collect maintenance from them. Like these are – all the tools that are you know demanding good budget from companies are really you know evolving quite quickly. So it’s really put a lot of pressure on vendors to innovate, otherwise they’re going to become stale and replaced by open source pretty quickly, which is a good thing for the uses of these tools I think at the end of the day. 

    Shimel: I also think that’s to Alon’s point that’s why OpenCore is such a great model for this, right?

    Dunne: Yep. 

    Shimel: Because you can’t – you can keep innovating at your core and then have your freemium, premium, whatever you want to call feature set kind of revolving around that core and keeping people, “Okay now that’s why I should pay money.” 

    Dunne: Right. 

    Shimel: So –

    Miranda: And I think –

    Shimel: Go Tracy. 

    Miranda: And I think we’ll increasingly see companies kind of use that to change the dynamic in the market and then they can use open source almost as a weapon to drive commoditization by saying, “Okay well this thing that was a premium feature for a number of vendors, we’re going to open source our vision” and you know suddenly change the dynamics. So it is real interesting because, yes, I think SAS services will make a big difference and everybody in the industry has to be on their toes constantly. 

    Girmonsky: Absolutely. By the way a way to compliment this is think of you know we used to live in an industry where the big vendors provide point tools, value, do something that you haven’t done before. Today, with developers it’s very hard to think of having an infrastructure that is not open source, right? So let’s assume the entire infrastructure is open source whether by vendors, by developers, or by big cloud like you know Netflix, Amazon and others. Then the next layer is efficiency and productivity. Then the commercial vendors they can provide impact by, you know, this is what I have done in BlazeMeter. It wasn’t — BlazeMeter wasn’t a load-testing tool. I think Flood was the same. It’s JMeter was the testing tool. 

    Dunne: Yep. 

    Girmonsky: BlazeMeter back then was all about making JMeter more efficient and the developers more productive. So suddenly LoadRunner wasn’t like, okay there is an alternative to what was de facto commercial tool, okay it’s the open-source tool, but as you said open  source on its own it’s pretty tough. So you know here come the vendors that make our lives more productive and use of open source more efficiently. 

    Shimel: Agreed. Kevin, Alon I’m going to put guys on a hot seat here for a second. You know what CNCF has been wildly successful in so many of the projects that they’ve incubated and now graduated and have been tremendous successes. Tracy, CDF is only what about two years old now? 

    Miranda: Yeah, not even. 

    Shimel: Yep, they’ve got four pretty amazing CD tools that are kind of de factor standards, right, that people are gravitating around. With such a strong heritage of open source and testing and continuous testing, automation, why haven’t we seen sort of the equivalent of the CDF in the testing world? Right? Why hasn’t the Linux Foundation or some other, Eclipse or Cloud Foundry or something or a new one sprung up that says, “Hey, we’re going to take these individual projects you know out of hands of individual company and do a community thing”? It may be a case of what, don’t break what’s, don’t fix what’s not broken, right, because it seems to be working the way it is. But why don’t we see a foundation for open-source testing? 

    Dunne: That’s a good question. I mean I think you know if I had to guess the main reason probably is just that you know testers are sort of developers, but sort of testers, right, and like an automated tester kind of falls in between the gap of maybe both and some view themselves as developers, some view themselves as testers. 

    I feel like it’s starting to happen. If you look at some of these tools like Cypress for example. You know the newer tools that are emerging definitely they’re communities have much more of like a developer feel around them and there’s much more structures of the open source contributions and whatnot. 

    But you know historically it was definitely very fragmented and you know the load testers all kind of rallied around JMeter and Gatling and you know the web testers around Selenium and the mobile testers around Appium. There’s really no common thread. I guess it’s kind of more like more siloed, right, versus my guess would be you know these tools like Kubernetes and you know Spinnaker or Jenkins, I mean those are ubiquitous, right? I mean everyone whether they’re building you know a web app you know in Java or in you know C# or whatever can use these tools versus I think a lot of the testing tools because they’re kind of like a thought you know into the decision that’s made after you make some decisions oftentimes on your kind of app infrastructure. That’s why they’re sort of thought of as maybe – they were historically thought of as more of an afterthought and the communities got more fragmented as a result of that. 

    But I think that is starting to change. I mean we know and we talked about these results on the last time I was on with you, Alan, you know that testers are becoming more and more like developers and becoming more technical, right? So I think the tools you know are going to demand to change this community structure, but it will take time but I think we’ll start to see that over the next few years my guess. 

    Shimel: Alon?

    Girmonsky: Yeah I think that if you look at the industry, the open-source industry for past second decade you know prior to CNCF there as Apache, right. 

    Shimel: Yeah.

    Girmonsky: Yeah and it was kind of you know in many ways the collection of open-source tools that if you’re in Apache open-source tool you’re probably in good. And now we see it’s not about open sources, it’s about what you do. Right? CNCF started mostly as Kubernetes and you know other tool and now the CD Foundation I think the focus is kind of all you know on the development lifecycle, as opposed to point tools and use cases it’s about the entire flow. 

    Actually I feel very comfortable. You know if testing finds its right position under CD because in CD you build, you test, right, these are the operations you do day-in-day-out. I would hesitate from having too many because it will kind of defocus many people, “I may do this,” “I may do that,” “Is it different?” Having like you know a family to belong to which is the continuous delivery continues deployment maybe in the future. I think it’s actually you know not a bad direction to take. 

    Miranda: Yes, absolutely and I think you’ve hit spot-on like CD continues deliveries is a process and I think that process does include testing and although we started off with these tools, which are all pipeline orchestration I’d love to you know CDF to future more open-source testing tools and certainly a lot of the conversations we have around interoperability testing comes up a lot. You know people are like, “Why isn’t there a standardized way to show pipeline results, the test runs” and why don’t we strive for that? That’s you know a problem that lots of end users highlight. So yeah, I’m all for you know having CDF be a place where we can have more of the testing community come together, seed, expand beyond kind of the traditional developer or and just make folks feel included in that community. So yeah, we should definitely talk. I like the direction [crosstalk]. 

    Shimel: So you heard, you heard it here first on DevOps Unbound. Alon, Kevin you have her contact info. 

    Dunne: Oh yeah. 

    Shimel: Let’s see some testing projects being part of CDF, right? Let’s bring it together. 

    Alon, the next line of questioning starts with you, but Kevin and Tracy feel free to jump in. So Alon you’ve been there, done that, you did BlazeMeter as you mentioned. You build it on JMeter and some other open-source stuff, but you didn’t want to duplicate what JMeter did, you were supplementing it and building on top of it. 

    Your present company, UP9 is new, not a lot of people are as obviously familiar with it as BlazeMeter. But I remember interviewing you when we first started talking about UP9 and you said, “Look this is for now, right, this isn’t what BlazeMeter…you know we took a lot of lessons that we learned and a lot of things that we saw, but this is for today.” What makes it for today, especially from an open-source perspective, right, that was different than when let’s say BlazeMeter you know first started with JMeter. 

    Girmonsky: Yeah. So BlazeMeter dealt with a problem that was irrelevant for 2010 or 2012, it was again it was kind of moving to the cloud, the Web-scale system, but mostly around service oriented architecture, right, and WebUp monolith of the time. At this time let’s say 2020 and going forward we’re talking about cloud native and containerized system. The industry took an approach to build the system that scales horizontally, right, with microservices. When you have than a few microservices you bring in Kubernetes or Docker Swarm or ECS sometimes, right, to orchestrate. 

    But this entire new tech stack it is far more complex than it was n the past and still you need to test. You have you know you call it not reliability, you have to have reliability case. You know you develop software you don’t want to develop faults that become failures, right? So and again it’s far more scalable in the past. If we used to do one service, now we have 200 services, dependencies, individual roadmaps, what do you do? 

    So UP9 takes care of it. UP9 provides a way to first test each and all microservices, like to provide the complete test coverage, but also do it you know use machine learning to offload a lot of the work from the developers. 

    Now to connect this with open source again I’m a strong believer that it’s not this or that, it has to be both. You have to start with open source because you first need to onboard your users, right? The only way to onboard them for them to have confidence is by giving them open-source tools and not because it’s free or because I want to make a name for myself in the open-source community, because that’s the only way to start you know the operation and then you make their lives, the developers’ lives more efficient.

    So this is UP9, UP9 start with open core solution that enables testing microservices in a Kubernetes ECS Docker kind of environment, but making it no matter how many services you may have, how many endpoints, whether it’s thousands of endpoints and hundreds of services you know you get things going pretty quickly, because you know this is how you would do things these days. 

    Shimel: Understood. Kevin, Tricentis I mean Alon’s example applies directly to Tricentis, right? You have three or four projects that you’ve spoken about, acquisitions that you manage, you know you’re managing these open-source communities and project, but yet there’s, you know there’s commercial or closed-source Tricentis. Where is the integration, where’s the overlap, where’s the leverage from one to the other? 

    Dunne: Yeah it’s a good question. I mean I think we’re kind of starting to see two different I would say maybe like communities of practice you know coming out of large IT organizations, right? You have definitely what Alon was talking about which is like kind of people building these I would call “systems of engagement,” right, which are customer-facing apps, that you know have all of these challenges around how to deal with containerization. So that’s where we really target a lot of our open-source tools, right, and open-source friend tools so that those people who really developing these web apps, mobile apps, you know web services in-house. But we’re also seeing that you know there’s this other large community as well, which is kind of all the systems of record, which should be maybe your main-frame systems, your package apps, like SAP, Salesforce, you know Workday. 

    And some of those communities, like some companies are starting to really start to try to do CI/CD and things like that around Salesforce and some of these more cloud-friendly apps, but for the most part a lot of those communities that kind of work differently they have different expectations, they usually are less technical and a lot of times would actually prefer sometimes a closed-source tool to kind of match the closed-source ecosystem that they’re supporting. 

    So that’s where I think you know when you look at it you kind of wonder, “Well hey how, why does Tricentis have both closed-source and open-source tools?” But I think you’ve got to have the right tool for the job and the right tool for the user, right? And so we see that you know you can-to-go and bring a highly technical tool to you know a nontechnical user that’s trying to test you know a very legacy package application. And vice versa you can’t bring you know a commercial tool a lot of times to a developer that wants to be you know able to write code and you know implement it into their DevOps pipeline and things like that and force them to take that approach. So rather than trying to you know have one or the other group suffer we’re sort of trying to bring together a platform which provides you know different tools for the different approaches. 

    Shimel: Tracy how does that jive with what you see with some of the pipeline tools and projects and companies in the CI/CD world with CDF?

    Miranda: Yep, no I think it’s really interesting and it was great to hear that distinction. So when look at cloud native and particularly Kubernetes and things sitting on top of that, I think the state is today that you still have to be highly technical to stitch a system together and to make it work and to keep up with all the updates. So it’s far, far away from being used very effectively by folks who are less technical or folks who want to be a bit more removed and just get a certain job done, but still take advantage of you know all the benefits of these containerized cloud-native systems. 

    So I think where the open source has to evolve there is to make that a lot easier. We talk a lot about kind of the developer experience and what that looks likes, because today like it’s really confusing if you had to come in new and figure out you know what tool to start with, how to put it together, take Kubernetes itself it’s got hundreds of distributions, which one do you even start? And then there’s a lot of confusing information as well for how you make decisions. 

    I think there’s a lot we can do in open source to drive some clarity on you know what are you trying to achieve, how do you get there, and how do you make the tools work together effectively and not leave it as an exercise to the user to figure out what goes with what. 

    Shimel: Agreed, agreed. Guys were coming … You know I could sit and talk about this with the three of you for the rest of the day, but we’re coming up on 45 minutes, which is kind of our cutoff here. Tracy you’ve heard what Alon and Kevin have said. So first of all guys I’m going to hold it to you. I’d like to see you reach out to Tracy and start and I’ll help, I’ll introduce some of my other friends in the open source and testing world and you have my commitment Tracy on that. I’ll do an e-mail intro. I’d love to see some testing projects become part of CDF. I’d like to see it expand beyond the pipelines to the real tools that folks are using in these things. 

    But you know Tracy CDF as you mentioned is less than two years old. We just last week we had KubeCon CNCF, Virtual Con, whatever I think it was called, what’s in store for CDF? What should our listeners be looking for? 

    Miranda: Yes, yeah, no, we are having our first big cdCon which will be virtual. It’s a first stand-alone event we have for bringing all the communities together. Because of COVID you know we’ve had to pivot quickly to going virtual. So you know it’s not going to be the same as in person, but it is going to be a really good way to bring people together and get that interaction. 

    So cdCon which October 7th and 8th and registrations are open now. That will be yeah just a really good way to come in and figure out what is the state of continuous delivery today and lots of different tracks on specialist topics and cloud native and of course lots and lots of open source. 

    Shimel: Don’t miss it. So that cdCon, October 7th and 8th, highly, highly recommend it. I’m sorry my Apple watch was ringing. There we had to shut that off quick. 

    Thanks Tracy. People can get information at that at CDF? 

    Miranda: Yes, as cd.foundation and find details there.

    Shimel: Great. Kevin, news around Tricentis open-source projects and products. 

    Dunne: Yep, yeah. I think for us you know like Tracy mentioned we’ve got to go virtual this fall as well, but we’re having our annual Accelerate conference this time online. We had one that was focused in kind of May on more of the US area, but we’re having more of a global one to come in October. So we’re going to be showing off a lot of exciting new stuff about a lot of the tools that I mentioned like test projects, SpecFlow, Flood. A lot of new integrations kind of between those tools and the core platforms. So starting to develop that story that I mentioned about sort of one platform to fit various different approaches, whether that’s more of the technical users or the nontechnical users. So that’s definitely one to check out. I’m just checking the date. I think it’s the 21st and 22nd of October is when we’re planning that for it I believe.  

    Shimel: It’s going to be a crazy October of virtual events. Alon, how about you and UP9?

    Girmonsky: Yeah, you know and the UP9 is a new startup. We started almost two years ago, but we are working diligently to complete our software. We already released our first version, but you know the work, still a lot of work ahead of us. So I hope to show you a lot of new cool things down the road. Now we are heads down you know building and building. 

    Shimel: Excellent. Guys I want to thank all three of you for being on DevOps Unbound with us today. I wish we had more time to dive into this. You know there’s so much. Even the idea of having a CDF versus let’s say five or 10 years ago if I told you we were going to have something called a “CDF” you wouldn’t believe me, right? You would think, “What do we need this for?” And you know so we’ve come so far in DevOps and continuous delivery and Kubernetes and — well Kubernetes itself is open source, but this whole revolution honestly around open source and community it’s what makes, it fuels so much of what we are seeing. You know where would we be in COVID without a lot of what we’ve, open source has enabled us to do you know using technology? So I do think it is, it is an integral, it’s a precursor to having the DevOps world that we live in today is open-source software. 

    So, thanks for joining us. We have to have you back on. I’m serious about testing tools in CDF though guys. I think that’s some, long, long overdue. Tracy, thank you and best of luck now that you’ve moved fulltime into the CDF. I know you’ll make great things happen there. Kevin, Alon, best of luck to both of your companies, UP9 and Tricentis. This is Alan Shimel for MediaOps, devopsy.kinsta.cloud. Thank you all. Thank you for watching. We’ll see you on the next DevOps Unbound, soon. Bye-bye everyone.