devopsy.kinsta.cloud

Category: Features

  • How ‘Some-Code’ Platforms Perform a Balancing Act

    How ‘Some-Code’ Platforms Perform a Balancing Act

    Recently, there’s been a surge of interest in visual programming models, all with varying degrees of user-friendliness. These low-code platforms utilize drag-and-drop elements to help citizen developers stitch together applications, avoiding the complexities of hard-coding connections. Such platforms are crucial amid a developer drought and shine in their usability. But, how usable is too usable?

    “A low-code platform should abstract complexity, yet always offer a way under the hood,” said Jesse Orshan of WayScript. In other words, the platform should never get in the way of advanced mechanics. To do so, “some-code” platforms balance usability and customizability.

    I recently spoke with WayScript co-founders Jesse Orshan and Lane Eden to see how some-code combines traditional coding and low-code. As opposed to a 100% visual no-code experience, some-code focuses on operational automation while granting a peek under the hood. Read on to see how the notion of “some-code” may set itself apart from the larger visual programming movement.

    Why Just ‘Some-Code’?

    To understand some-code, consider the greater industry. As I recently covered, many factors are spurring a low-code revitalization. One is the need for rapid development for internal tools. Orshan acknowledged how “cumbersome, costly, and time-consuming it is to build and maintain internal tools.”

    Many developers are fully capable of, for example, programming a native iOS app. Yet, turning that into a business application with a back-end running in the cloud with the proper databases, server arrangement, access management, and continuous deployment strategy is a whole different story.

    “The idea is to blend coding and low-code,” Orshan said. “Scaffolding is the most difficult part of development.” Therefore, a some-code platform provides an operational toolset—a framework that enables developers to focus on their application logic.

    Some-Code Leverages Event-Driven Architecture

    Event-triggering has become common within modern programming. Triggering is necessary for automating tasks and workflows involving interconnected tools.

    For example, say an internal tool for a sales department must automatically update a lead spreadsheet and send a Slack notice once an email is received from a prospective client. This process requires scripting a series of API queries involving Gmail, Salesforce and Slack APIs.

    Though the logic seems simple from the outset, hooking together applications is not a trivial task. “Building a robust triggering system that can scale with your load is a very complicated thing to do,” said Eden. HTTP API integration is a unique skill that not all possess. “Thereʼs an understated art to building good APIs,” according to an Increment blog post.

    The hurdles of API integration have already given rise to drag-and-drop workflow services such as IFTTT and Zapier. Some-code applications, too, could quickly enable developers to mix-and-match APIs in the programming language of their choice.

    Other Some-Code Benefits

    Internal tooling can be a big pain point. It’s “bespoke and custom to every business,” said Orshan. Utilizing drag-and-drop components alongside an IDE, some-code could lower the DevOps barrier for constructing enterprise-grade interconnected applications that require testing, auto-build and deployment automation. Here are some other some-code benefits:

    • Abstracted type system: APIs are at the heart of many low code initiatives, enabling integrations with third-party tooling to enable event-based modeling. Some-code could enable developers to program logic without hardcoding integrations, offering a “unifying system abstracted type system,” noted Orshan.
    • Flexibility: A unique prospect of some-code is that it could retain the programming language developers are accustomed to.
    • Aids rapid development: Some code seeks to abstract things away, making it easier for developers to quickly solve core problems.
    • Fill integration talent gap: A lack of specialized talent encompasses integration engineers and IT security disciplines. According to OutSystems, 45% of businesses adopt low-code to reduce dependency on hard-to-hire technical skills.

    The Reality of ‘Citizen Development’

    Problem-solvers come in all skill sets. Some are programming novices with little know-how, and UIs cater well to this group. However, only 8% of companies say they have business users utilizing a no-code platform without IT intervention, according to OutSystems’ 2019 State of Application Development report. Instead, the majority of low-code users are professional IT developers, at 69%.

    “There is a place for visual elements, and there is a place for coding,” said Eden. “Sometimes, writing a function in Python is just way more efficient.”

    Though low-code providers may trumpet the citizen development ideal, in reality, in 2019, only 20% cited enabling citizen developers as a key reason for adopting low-code. Perhaps this need will increase subsequent a fully remote economy and a developer talent shortage. Yet, as of now, experienced software developers are the ones using and benefiting from low-code tools.

    Final Thoughts

    The usability of no-code empowers business technologists to build basic workflows, yet lacks deep customization abilities. Yet, pure manual programming slows when you consider the many web APIs, differing standards and DevOps tooling integrations necessary to deploy modern enterprise-grade cloud applications.

    The premise behind some-code is to help skilled developers stitch the operational scaffolding around their source code, helping integrate, validate, test and deploy software in a more streamlined approach. This style could be a better balance for advanced developer teams requiring an extra push.

    “Our guiding philosophy is there should always be a way to get under the hood,” said Orshan. “The platform should never get in the way.”

  • The Pros and Cons of Configuration-as-Code

    The Pros and Cons of Configuration-as-Code

    Configuration-as-code, or “GitOps” as many are now calling it, is a simple but astounding idea: Standardize configuration, check it into version control; no need for each Operations/DevOps person to develop their own set of scripts to get the job done. Configuring or reconfiguring an environment is as simple as checkout and run, assuming everything in the configuration is tested. For a project or a team, this is a serious time-saver and limits the amount of human error introduced into our systems. For projects rolling out code frequently, it is pretty much required.

    But like everything, it has its limits. I worked with a product management engineer once who had concocted a script that had tens of thousands of lines of code and was every bit as complex as the product he used it to manage. His scenario was the typical precursor to configuration-as-code: He would go show off the product and whatever functionality he needed could be managed through his script. The problem was maintenance; as the script was central to how he did his job, changes to it were a big deal. And even though he was the only one maintaining it, he did get burned a couple of times by changes he’d made, because it was that complex.

    When our configuration-as-code starts to cross teams, or we take it to the enterprise level, we risk finding its limitations. Our environments are complex, very complex. And we can do a lot with configuration-as-code, but throwing everything plus the kitchen sink into that system will create issues we need to overcome.

    A single project is constrained. We know what we need to do to spin up the environment. We can identify weak points and build checks and balances around them.

    The enterprise environment is not a project. Agile projects and DevOps thrive because they have a stable working environment to run on. The volume of change in things such as storage allocation, routing and VLANs is not the volume of change that an agile project sees. Good documentation is as solid a solution as configuration as code for something that changes rarely and the size/number of scripts and configurations that need to be maintained is smaller.

    There is a good use case for corporatewide configuration-as-code for recovery purposes. It is far easier to restore the environment in a disaster if you have all configuration and the scripts to install that configuration available. Unfortunately, that use case is minimized by the march of technological change. During the one total destruction restoration I’ve been involved in (was in charge of), many of our configurations were no longer usable because the products we were running in production at the time of the disaster were not the products we could purchase for the rebuild. We ended up with a shiny new data center from building to servers, but it still involved a lot of manual configuration. So while the use case is good, it is not a panacea unless you are constantly replacing your infrastructure with the newest products, limiting the usefulness of this use case also.

    Some organizations have already moved to configuration-as-code via methodologies such as chaos engineering, but most of us are just starting to consider moving configuration-as-code beyond the project level. When the (admittedly large) step of truly moving infrastructure management toward configuration-as-code, start with inventorying what your operations team does on a daily basis. There are a ton of things—the famous low-hanging fruit—that can be boiled down to scripts or standardized configurations and checked into version control. This gives a central point of truth for how things are configured, tracks changes for when things go wrong, and shortens startup time for new DevOps/Operations staff by giving them a repository of tools to review and work with. When working in the cloud, everything is scriptable, so make that side of operations is completely configuration-as-code. In the data center, you end up with diminishing returns after daily tasks are automated, but assigning someone to codify all possible changes is a worthy goal, as long as the work is prioritized to make the most frequent or error-prone configuration issues a priority. Once the focus is down to hardware, the rate of return for those invested hours is going to go down a bit, since specialized hardware is full of proprietary or market-focused config info. To draw on a comparison I’m familiar with: An F5 ADC has very specific use cases that must be reconfigured centrally, whereas restoring your Kubernetes cluster will generally require less focused configuration and teams spinning up containers will take it from there. Not that Kubernetes configuration is simple; but each project handles the details they require while corporate-shared resources tend to need all of the details handled by the infrastructure team.

    We can discuss this at length, and I have with others who think differently, but small tools are better. Do one thing, and do it well—the original Linux mantra—then make scripts that call the small ones. This contains changes over time and doesn’t create dependencies or touches on things that might not need it in a given situation.

    And keep rocking it. All configuration-as-code does is reduce manhours and opportunity for human error, so embrace it, but be controlled about it. Don’t throw everything in there and then forget about it. Make a plan, make a maintenance plan. Iterate. Improve. And use that extra time to solve user problems, which is why we’re here in the first place.

  • Low-Code: An Oasis During Developer Drought

    Low-Code: An Oasis During Developer Drought

    Key insights from Mendix’s 2020 Developer Drought Index

    You may have heard that Silicon Valley is in the midst of a developer drought. But the Valley is not alone; developer talent across the U.S. heartland has dried up. In fact, the top 10 U.S. counties with the highest developer demand per capita aren’t even in California.

    A recent report by Mendix identified new hiring hotspots and a changing U.S. map for tech talent. States in the U.S. heartland are actively seeking developer talent, though some are slow to adopt 100% remote work. In the wake of COVID–19, many are reassessing work-life opportunities, leaving densely populated cities to work and live in more rural areas.

    I recently had a great discussion with Sheryl Koenigsberg, head of global product marketing at Mendix, to make sense of the “Developer Demand Index” findings. Below we speculate on the future of developer work, and how low-code platforms may be the oasis many talent-thirsty companies seek.

    ‘Developer Demand Index’ Study

    The “Developer Demand Index” sought to identify locations where developer talent is needed the most. The process involved a geographic analysis of 2,000 of July 2020’s job ads for U.S. software developers.

    The study found high developer demand and short supply in middle America; South Dakota, Nebraska and Utah were among the top states with the lowest supply to demand.

    At a county level, the highest developer demand was in Cumberland County, New Jersey; Minnehaha County, South Dakota; and Pontotoc County, Mississippi.

    The study demonstrated how more established tech hubs—Silicon Valley and Austin, for example—have a better balance of talent demand and supply.

    “The study confirmed unpopular theories that I had,” said Koenigsberg. “Developer drought is not a Silicon Valley or coastal-only problem; smaller metros throughout the country are experiencing the same problem.”

    Conditions for a Drought

    Why do states in the nation’s heartland have a developer drought to begin with? I assumed that a lower average salary in middle America would deter developers, but Koenigsberg said the conditions are more complex.

    “I don’t necessarily see a correlation between average salary and developer drought,” she said. Rather, new tech hubs continue to form wherever larger enterprises can get tax breaks. Other regional perks could include local government startup incentives or university partnerships.

    Tech certainly has a history of revitalizing less dense areas with new hubs. Take Google’s expansion into Austin, Amazon’s takeover of Seattle’s South Lake Union neighborhood or SpaceX’s remote Starship site in Boca Chica, Texas. Naturally, these areas attract the requisite talent and encourage other companies into the fold as well.

    For example, the report speculates South Dakota state could be a new Silicon Prairie hotspot. “A vibrant tech & startup scene, local talent, and the lowest COVID–19 rates are all driving the economic surge in this state,” read the report.

    With remote work and social distancing brought on by COVID–19, technology companies are adapting and the urgency to cluster in certain locales may dissipate.

    COVID–19 and Remote Work

    Software was already eating the world. But with COVID–19, it’s eating physical reality itself.

    With COVID–19 forcing many companies 100% online, the need for new software is skyrocketing like never before. Google, Facebook and many others have enacted stay-at-home plans for most of 2021. After the crisis, remote work will be a more permanent reality for many.

    While COVID–19 benefited tech, many brick-and-mortar businesses were less prepared. We’re now seeing the frailties of old systems, described Koenigsberg, and the need to replace paper-based or manual operations with digitized versions. Consumer-facing companies that did not vigorously embrace digital transformation before COIVD–19 are now in a tight spot.

    Low-Code Waters Fill a Developer Drought

    According to Derek Roos, CEO of Mendix, “the ‘Developer Demand Index’ shows that companies need to think differently about how and where to engage skilled tech workers in 2021 and beyond. Traditional development paradigms basically fall apart when you’re dealing with mobile or remote workflows.”

    As I covered recently, COVID–19 is only one of many factors spurring a low-code revolution. By utilizing visual-based models, “citizen developers” can construct applications. This enables a business analyst, for example, to string together an internal application without jumping through the traditional IT hoops. Koenigsberg identifies other low-code benefits:

    • Hire Local: If tools are less impenetrable, companies can retrain local employees, helping recover the developer gap and negating the need to hire externally.
    • Collaboration: Low-code aids remote work, enabling pair programming where teams work on the same model simultaneously.
    • Domain Expertise: Citizen developers with niche domain knowledge can better optimize applications to their industry needs. Knowing a factory production yield, for example, can help better construct a manufacturing application.
    • Women in Tech: Koenigsberg notices significantly more female involvement at low-code themed events. Hopefully, low-code can have a balancing effect on gender participation in tech.

    Final Thoughts

    The Mendix “Developer Drought Index” revealed areas of high demand and short supply throughout the U.S. Interestingly, 92% of the job ads analyzed in the study required a specific location. Regardless, the report concludes there are compelling “opportunities for companies and individuals to decentralize talent away from established tech hubs using virtual teams and cloud technology.”

    Low-code seeks to democratize software development to keep deployments on pace with the intense demand for software. Of course, low-code is no cure-all, and Developer Drought locations will likely still seek external or offshore hiring to supplement. However, low-code may offer the respite needed during uncertain times.

  • GitLab Presses Case for DevSecOps Collaboration

    GitLab Presses Case for DevSecOps Collaboration

    GitLab today at its GitLab Commit Virtual event pledged to make securing its open source continuous integration/continuous delivery (CI/CD) platform a more collaborative effort.

    Cindy Blake, senior security evangelist for GitLab, said the company is committed to sharing a road map developed in collaboration with DevOps teams that lets organizations see what cybersecurity issues will be addressed when.

    Rather than merely sharing DevSecOps marketing collateral, Blake said the goal is to encourage engineers to participate in a feedback loop that will help prioritize what issues need to be addressed across a shared DevSecOps agenda.

    Most of that effort thus far has focused on making tools for scanning for vulnerabilities a natural extension of a DevOps workflow by embedding them into GitLab Core. Most recently, GitLab acquired Peach Tech, a provider of protocol fuzz testing and dynamic application security testing (DAST) API testing tools, and Fuzzit, a continuous fuzz testing tool. The company also moved to make its CI/CD platform available as a set of hardened Docker container images.

    The next priority is to enable organizations to construct DevSecOps workflows spanning DevOps and cybersecurity teams, said Blake, noting it will be easier to construct workflows at scale using a CI/CD platform that tightly integrates all the tools required.

    In time, GitLab plans to extend those efforts to include machine learning algorithms that will be trained to identify and remediate cybersecurity issues, she added.

    As a founding member of the Open Source Security Foundation, GitLab is also committed to working with the rest of the open source community to better secure software, Blake said.

    There’s naturally a lot more focus these days on application security. A recent Global DevSecOps Survey conducted by GitLab finds developers are exercising more control over security—more than 25% of developers reported feeling solely responsible for security, compared to 33% of security team members who say they own security. A total of 29% of respondents said they believe everyone should be responsible for security.

    However, cybercriminals are also making a concerted effort to compromise software supply chains by inserting malware into DevOps workflows constructed on CI/CD platforms. The challenge with securing open source platforms, of course, is the code employed to build these platforms is accessible to anyone including, of course, cybercriminals.

    It’s too early to say to what degree cybersecurity concerns are influencing the selection of CI/CD platforms. However, as cybersecurity professionals become more involved in application development, it’s only a matter of time before issues involving the security of the platforms used to build applications become a higher concern.

    In the meantime, the line is blurring between application development and cybersecurity. The challenge for each organization will be determining just how far left they want to shift responsibility for cybersecurity to the individuals who build their applications versus a cybersecurity team that has a less vested interest in accelerating the rate at which code is promoted into a production environment.

  • DevSecOps and Passwords: Lessening the Burden

    DevSecOps and Passwords: Lessening the Burden

    The point of DevOps is to make IT more responsive (and hopefully more stable, but we have evidence that is not always the case). The point of DevSecOps (so far) is to make security more responsive and to build security right into the stack. These are both worthy goals. As we all have pointed out repeatedly, an already overworked security team needs DevSecOps to keep up with the increased rate of change that a more responsive IT department represents.

    And yet, while we’re automating and simplifying things, the security end of DevOps is doing little for end users. Automating protection of App X is good for the App X team and good for the company, but it means little to the ultimate users of security. We all know security is a burden that users bear in the hopes of protecting the company, but no one is a fan. So maybe you didn’t have self-service password management, and now you do. Great! That helps end users. But most of us were already implementing self-service in an attempt to lift some of the load off of the security and help desk teams by the time DevOps took hold.

    Maybe you’ve implemented SSO as a result of DevOps. Again, good move! Employees spend less time remembering passwords and more time being productive. There’s less stress, too. But again, that was already well along, DevOps or not. And you know what? Employees are still making passwords they can remember, writing down passwords, re-using the same complex password, etc. To make it more difficult to hack, IT has come up with all sorts of strange rules such as, “Password digits, when summed, must be divisible by the square root of pi …” but that does little if the same password is used for LinkedIn (because it is “work-related”) and LinkedIn gets hacked again. And don’t fool yourselves, I know tech-savvy people who do this. Non-technical people are doing it a lot if techies are doing it.

    Which brings us to my suggestion: Your DevSecOps plan should include a password manager budget. There are a ton of them available, they’re cheap enough no matter which one you choose and they will generate complex passwords and then remember them for the user. Give employees password managers, train them a bit on their use, and reduce the chances that their password is the same as the one they used at pleasehackme.com. The investment is small—a few dollars per user for most managers—and choices include vaults that are local or hosted and the ability to set password-generation parameters.

    The only problem with a service-based password manager is ownership of the account after the employee leaves the company, but a policy can clearly delineate when responsibility transfers to the user and arrange for removing them from systems at the same time.

    More secure, less user hassle (true single sign-on, since they only need to know the password to the password management tool) and low cost—this is the heart of DevSecOps. And the investment is small. A bit of cash, a bit of training. What’s not to love?

  • 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—DevOps.com 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 DevOps.com, 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.

  • MediaOps Makes the Inc. 5000 List

    MediaOps Makes the Inc. 5000 List

    Here at MediaOps we have two big announcements today. The first is that we have earned a place in the Inc. 5000 annual ranking of the fastest-growing companies in America. We didn’t just make the list—we came in at 1,622, well in the top half of companies on the list.

    The other announcement is that we have relaunched our MediaOps website, at mediaops.com. With updated positioning and messaging, our new site better reflects who we are today and what both our sponsors and visitors want to know about us.

    Both of these announcements are linked in a way that may not be obvious to the casual observer. As the founder of this company, I am extremely proud of what we have accomplished that has resulted in our earning this honor. When I look at our new website and its impressive information about MediaOps, I am even more proud. But I am most proud when I look at the team page and look at the great group of people who make up our team.

    To give you some background for insight, we started this company about seven years ago with DevOps.com. It was going to be a blog with myself as the primary author. But even then we had plans that maybe there would be more. We chose MediaOps as the corporate name in case we ever did more than DevOps.com. My partner Martin Logan came up with the name, actually.  But when we went to register the domain, we could not get the Mediaops.com name. Instead, we registered MediaOps.io, figuring it wouldn’t make much of a difference because no one would know our corporate name anyway.

    MediaOps and the MediaOps website shared a common theme. We really didn’t care if anyone knew the name or the website, really; we didn’t have the bandwidth or resources to promote that in addition to DevOps.com. Parker Yates, our Chief Revenue Officer, and I developed many of the sponsored services we offered, which were centered around DevOps.com and then its associated properties.

    With the launch of Security Boulevard and Container Journal, we again put whatever resources we had toward establishing those brands in their own right. We never really had a focus on the MediaOps brand and MediaOps website.

    Equally so, we really never thought about MediaOps being a fast-growing company that would become one of the fastest-growing companies in the U.S. Who had time for that? We were too busy delivering the next webinar, the next article, attending the next conference. Our mission was to help grow and establish the communities we lived in.

    Today, MediaOps is a different company than it was seven years ago. We are more than 20 people strong, operate over a dozen different websites and all the other great metrics that go with this kind of success. We began to realize that our hard work was resonating and our sponsors looked to us as a reliable partner in delivering thought leadership, branding and lead generation activities. Our audience has come to expect quality content across all available channels.

    We developed beyond the written word. Our virtual events, video, audio and even comics are different distribution channels to the same audience we serve: DevOps, Digital Transformation, Cyber and Cloud-Native. Taking our audience focus and our means of distribution, we call this the omniverse.

    Our new website at Mediaops.com (we thought it was time to buy and own the domain) reflects all of this and more. Despite the current COVID-19 crisis, MediaOps is well-positioned to build on its success. In the weeks and months ahead, we will continue to make more announcements and bring new activities to the MediaOps omniverse.

    Finally, I want to thank you, our audience, most of all. None of this success would be possible without you. Thanks for the support, thanks for being who you are. Our mission really hasn’t changed: We will continue to bring you the best content we can find via every channel we can use to contact you. That is the Mediaops Omniverse.

  • Upcoming Event: Operationalizing Kubernetes Virtual Summit

    Upcoming Event: Operationalizing Kubernetes Virtual Summit

    As Kubernetes keeps gaining traction in mainstream IT environments, the next big challenge IT teams will face is operationalizing the platform at scale. On Oct. 1, at 10 a.m. EDT, leading Kubernetes and cloud native communities will come together at the Operationalizing Kubernetes Virtual Summit to explore the tools and best practices you need in order to secure and manage one of the most powerful, yet complex IT platforms in the world.

    Today, organizations are managing not just one or two Kubernetes clusters, but entire fleets as their infrastructures increasingly depend on Kubernetes for automating deployment, scaling and operations of applications. As such, operationalizing Kubernetes is paramount to a successful environment.

    The free, interactive virtual conference brings Kubernetes technologists, DevOps and cloud-native experts together to share their knowledge and insights with the community. Attendees will find out how organizations such as AWS, Microsoft, CloudBees and many others are embracing containers and microservices environments.

    Operationalizing Kubernetes Virtual Summit features an exceptional lineup of industry leaders, including:

    • (Keynote speaker) James Strachan, distinguished engineer at CloudBees
    • (Keynote speaker) Priyanka Sharma, general manager at CNCF
    • (Keynote speaker) Liz Rice, vice president of open source engineering at Aqua Security
    • Tracy Miranda, director of open source community at CloudBees
    • Michelle Noorali, senior software engineer at Microsoft
    • John Willis, senior director of the Global Transformation Office at Red Hat
    • Bob Reselman, analyst at Accelerated Strategies Group
    • Prashanto Kochavara, director of product at Trilio
    • Pankaj Gupta, senior director of product marketing at Citrix

    The virtual environment features a lobby, an expo hall lined with booths full of downloadable resources and an auditorium where attendees can watch the sessions by industry experts. Attendees will have the opportunity to interact, in real time, with speakers and sponsors, and will have the chance to participate in contests to win incredible prizes.

    Stay tuned for speaker announcements and more summit details. For more information and to register, visit the Operationalizing Kubernetes Virtual Summit.

  • DevOps Unbound: Exploring Acceleration and Automation, Setting DevOps Free

    DevOps Unbound: Exploring Acceleration and Automation, Setting DevOps Free

    We are launching a new video series Thursday, Aug. 6, called DevOps Unbound. DevOps Unbound will focus on DevOps, automation, CI/CD and testing, featuring leaders in these areas as we explore the challenges and issues software delivery and IT teams face every day. How do we go faster, smarter with better quality? DevOps Unbound!

    The series will premier on our TechStrong.tv streaming network and should start around 10:40 a.m. Eastern tomorrow, August 6th. It will be available on Linkedin Live (on the DevOps.com page), Facebook Live (DevOps.com, Container Journal or Security Boulevard pages), YouTube on the DevOpsTV channel and the MediaOps sites. Additionally, the show is available on-demand on our DevOps.com mobile app and our DevOps.com OTT channels on Roku, Apple TV and Amazon Fire TV. Finally, all episodes will be available on-demand on Digital Anarchist, our streaming video platform. The series is sponsored by our friends at Tricentis.

    New episodes will run every other week. Also planned is a monthly DevOps Unbound roundtable, open to the public and featuring a revolving panel of experts around a given theme. The first live monthly roundtable will be Aug. 18, around the theme “DevEverythingOps.” Roundtable discussions do require registration; you can register for the first event here.

    Premier Episode August 6th

    The premiere episode features Dr. Grigori Melnik, CPO of Tricentis, and James Bach, the developer of session-based testing and a highly respected expert in testing. We will explore the history of testing and how it has adapted over the years to allow for more automation, help testers and developers be more efficient and accelerate the software release process.

    These are two people renowned in their fields who arrived here from very different paths. Bach is a high school dropout who was bitten fiercely by the computer bug. He was a game developer and then a coder who became one of Apple’s first test engineers in 1987. Dr. Grigori Melnik has a Ph.D. in testing and is a respected authority in both the academic and business worlds.  Though they come from different backgrounds, they have more in common than you might think. It was a great discussion and one I think you will really enjoy.

    Future episodes of the bi-weekly show will feature topics including DevSecOps, open source, cloud-native, CI/CD, SDM, DataOps, observability and more. We think DevOps Unbound will quickly become an essential part of your DevOps information arsenal.

    We are always on the lookout for future topics and guests. If you think you would like to take a giant leap with DevOps Unbound, reach out to me at unbound@devops.com with your idea and we can follow up.

    BTW, DevOps Unbound is just one of several new shows we are premiering on TechStrong TV and Digital Anarchist. Another is CISO Talk, featuring Unisys CISO Mathew Newfield and me. That will be on TechStrong TV this coming Monday. More announcements to come about new, recurring shows.

    We recognize that people want to see video content and at MediaOps/DevOps.com we are producing lots of exciting new video content. Stay tuned.

  • Upcoming Event: GitLab Commit Virtual 2020

    Upcoming Event: GitLab Commit Virtual 2020

    For the first time ever, GitLab’s annual user conference will take place in a virtual environment on Aug. 26, bringing together DevOps luminaries from around the globe for a free, interactive learning experience.

    GitLab Commit Virtual is a 24-hour virtual event that provides attendees with the opportunity to join DevOps discussions, demos and presentations, and network with thought leaders from the industry’s top companies, such as Microsoft, Google, Hubspot, Forrester and many more.

    Speakers will showcase the power of community and share DevOps best practices through strategy and technology discussions, lessons learned, behind-the-scenes looks at the development life cycle and more.

    The agenda for GitLab Commit Virtual features a mix of topics, including technical sessions, live coding, deep-dives and case studies covering DevSecOps, containers, Kubernetes, CI/CD, open source, all-remote and more.

    The virtual environment features a lobby, an expo hall lined with booths full of downloadable resources and an auditorium where attendees can watch sessions by industry leaders.

    This year’s GitLab Commit features more than 40 sessions from some of the most brilliant DevOps experts, including:

    • “DevOps Works! Why Hasn’t Security Kept Up?,” a keynote session by Joni Klippert, StackHawk.
    • “DevSecOps in Government and Highly-Regulated Industries,” a keynote session by Nicolas Chaillan, U.S. Air Force.
    • “Real World DevOps,” by Abel Wang, Microsoft.
    • “Why Your Organization Should Embrace the Community Model,” by Karl Cardenas, State Farm.
    • “Getting Fuzzy: Blurring the Lines of Traditional QA and Security Testing,” by David DeSantos and Sam Kerr, GitLab.
    • “How the U.S. Army Cyber School Created ‘Courseware as Code’ with GitLab,” by Ben Allison, U.S. Army Cyber School.
    • “Measuring DevOps,” by Nathen Harvey and Dina Graves Portman, Google.
    • “How To Create an Equitable and Inclusive Culture That Transcends Physical Walls,” by Eimear Marrinan and Meaghan Williams, HubSpot.

    By visiting the expo hall, attendees will also be able to interact with sponsors, including AWS, Google Cloud, Lightstep, HashiCorp, Red Hat, VMWare Tanzu and WhiteSource.

    Attendees will get a deep dive into how enterprises are transforming DevOps at an organizational level and how they can implement similar practices in their own organization.

    To see the full agenda and to register, please visit the GitLab Commit Virtual website.