devopsy.kinsta.cloud

Category: Blogs

  • Low-Code and the Rise of the Citizen Developer

    Low-Code and the Rise of the Citizen Developer

    Low-code technologies have become increasingly popular for helping businesses adapt to ever-changing environments quickly by allowing them to build, customize and deploy apps with little to no coding. At Low-Code/No-Code Virtual Summit, taking place on Nov. 18 at 9 a.m. ET, luminaries of leading organizations in the low-code community will share valuable insights on their digital transformation journeys and the role of low-code/no-code in their digital strategies.

    Attendees will get an intimate look at how organizations are embracing low-code technologies to advance their business while improving user experience. The virtual event explores the vast and growing ecosystem of technologies that are changing the face of application development, featuring sessions on:

    • The rise of the citizen developer
    • Security and compliance in low-code applications
    • How low-code is transforming software development
    • Low-code versus no-code
    • Low-code trends

    Low-Code/No-Code Virtual Summit features an exceptional lineup of low-code and industry experts, including:

    • Derya Sousa, co-founder and COO at Kianda Technologies
    • Venkat Thiruvengadam, CEO at DuploCloud, Inc.
    • Andrew Manby, head of product management at HCL Software
    • Asna Javed, hybrid cloud build team and developer advocacy leader at IBM
    • Eren Akbaba, cloud architect at IBM
    • Charles Kolodgy, cybersecurity strategist, advisor and educator at Techstrong Research
    • Daniel Topham, CEM for digital, strategic solution architect at Everbridge
    • Bala Madhusoodhanan, principal architect at TJX
    • Paul Porter, VP of sales engineering at Everbridge
    • Gunndarr Dotter, regional sales director at HCL Software
    • Amy Hart-Koullapis, communications systems specialist, global marketing and communications at World Vision International

    The virtual environment features an auditorium where attendees can watch the sessions by the experts and an exhibit hall lined with booths showcasing the latest solutions from leading low-code companies. In the exhibit hall, attendees can download resources and interact with partner sponsors.

    To start off the event on a high note, we have scheduled a yoga class at 9 a.m. with a certified instructor.

    Registered attendees will receive a link to access the virtual environment on-demand for up to 30 days after the live event.

    To check out the full agenda and to register for free, visit the Low-Code/No-Code Virtual Summit website.

  • Data Theorem Adds Runtime Protection Enabled by Observability

    Data Theorem Adds Runtime Protection Enabled by Observability

    Data Theorem, Inc. this week added an Active Protection offering to its portfolio of application security services that makes it possible for DevOps teams to embed observability and runtime defenses in their applications via a software development kit (SDK).

    The Data Theorem cloud services are based on Trustkit, an open source framework the company created to make it easier to employ secure socket layer (SSL) to encrypt connections and Analyzer Engine, its runtime analytics engine.

    The company is now extending its services to make it possible to embed observability capabilities by collecting logs and traces. Those logs and traces are then used to enforce runtime security policies that protect applications from known attacks from malicious sources and other common attack vectors as defined by the Open Web Application Security Project (OWASP) Foundation. It also prevents violations of encryption levels, authentication types and authorization rules along with a variety of custom rule checks, including preventing broken object-level authorization (BOLA) attacks.

    Doug Dooley, Data Theorem COO, said Active Protection can be applied across any application stack, including microservices applications based on cloud-native frameworks. In contrast, existing approaches to securing application runtimes based on web application firewalls (WAFs), runtime application self-protection (RASPs) or endpoint detection and response (EDR) agents cannot be applied to cloud-native applications based on containers and serverless computing frameworks.

    Active Protection solves that issue because it is designed to be applied via the Data Theorem software development kit (SDK) or using application extensions made available via a serverless computing framework or as a container sidecar.

    Dooley noted that the Active Protection service is also designed to be fully integrated with DevSecOps workflows that are increasingly being driven via continuous integration/continuous delivery (CI/CD) platforms to enable continuous, automated security inspection and remediation. The company claims to have detected more than one billion application incidents and is currently used by more than 8,000 applications.

    Developers don’t generally set out to build and deploy insecure applications. The issue is most developers don’t have a lot of security expertise, so it’s easy for mistakes to be made. Organizations looking to embrace DevSecOps best practices need to find a way to achieve that goal in a way that developers can easily embrace. The more automated the checks for security issues become during the application development process, the more likely it is developers will make additional efforts to remediate vulnerabilities long before an application is ever deployed in a production environment. In effect, DevSecOps is easier to achieve when addressed from the bottom up rather than via an edict from above without any real implementation plan in place.

    It’s still early days as far as DevSecOps is concerned, but as best practices for DevOps continue to evolve, there may come a day when security is just another gate that needs to be passed within the context of a larger DevOps workflow. In the meantime, DevOps teams and cybersecurity teams should put aside their differences and work together as the number of attacks launched against applications increases.

  • 4 Strategies to Manage Freelancers with In-House Dev Teams

    4 Strategies to Manage Freelancers with In-House Dev Teams

    Remote workers are a growing segment of the global workforce. Freelancers account for a big part of that segment, especially when development teams need to bring in specialized skillsets for upcoming projects. Working with freelancers offers many benefits, but there can also be challenges when integrating freelancers with in-house teams.

    Here are four strategies to help in-house developers effectively manage freelancers in their development teams:

    1.    Keep Remote Workers in the Loop

    Don’t leave freelancers and remote workers in the dark about your overall business direction and goals. If a freelancer is only joining the team temporarily to handle one part of a project, it might not seem necessary to give them the full details about the project’s goals and the reasons behind your decisions.

    However, providing this information enables every member of the team to fully understand what you need from the products and features they are working on and how they will serve the end user. It also helps to create common goals and motivations that the team can work toward together, rather than keeping your remote workers’ tasks separate from other members of the development team.

    2.    Make Consistent Feedback a Priority

    In an OfficeVibe survey, 96% of employees said they wanted to get regular feedback from their managers, but 32% said they receive feedback less than once every three months. Freelancers and remote workers arguably need more feedback than in-office employees, for several reasons.

    Freelancers and remote workers are often less exposed to the wider business context in which they are developing products and features. This can make it harder to assess and optimize their output from the viewpoint of an end user. Just as importantly, it can make it less clear what the other members of the team are working on and how their output affects their colleagues’ work.

    “Without consistent feedback, even the most talented developers in a team can invest a lot of time in a non-feasible solution. An ongoing feedback loop is one of the best ways to support a team and enable them to put their skills to use,” said Irene Avdus, a product manager at TextMagic, which has offices in multiple countries and which regularly brings on freelance talent.

    Giving freelancers and remote workers consistent and regular feedback doesn’t just help them improve their output for a better end result. It also helps them to fit in with the workflow of the rest of the team, enabling the project to go more smoothly for everyone.

    3.    Provide Growth Opportunities

    “Great leaders invest in their employee’s career development and steer them from being a one-trick pony,” said Phidelia Johnson, Pac-J Investment Services executive director of HR.

    When it comes to upgrading a team’s skillset, companies tend to skip over freelancers and remote workers in favor of employees they see as more permanent. However, opportunities to develop skills and advance their career are just as important to remote workers and freelancers as they are to any other employee.

    As a result, the perception of remote workers and freelancers as more temporary team members can be a bit of a self-fulfilling prophecy. When companies don’t invest in developing employees’ skills outside of their in-house teams, it is to be expected that remote workers will move on after the project is done to advance their careers.

    Often, treating remote workers as temporary doesn’t result in any less training, anyway. Whenever you add a new freelancer to your development team, there will be a certain amount of training and onboarding necessary to get them up to speed with how your team works. In fact, this can often be a major time and resources investment

    “In a lot of situations, the biggest challenge of working in data engineering or BI is not learning technology X or Y—it is being able to pick up quickly all the business rules and processes of the department you are building your pipeline or dashboard for,” said Mohamed Khalil Ouachikh, ArmedAngels data engineer and BI specialist.

    Rather than spending time onboarding new remote workers with each development cycle, investing in upgrading and expanding the skills of current team members and freelancers can result in a more capable team that is already familiar and comfortable with your business and the needs of your clients.

    4.    Informal Team Meetings

    Making people feel like part of a team is important to ensure they can collaborate and coordinate effectively with other members. Both of these factors are crucial to developing any successful product.

    Why is this relevant to managing freelancers in your development team?

    Remote workers don’t have the same opportunities to connect with colleagues as in-house employees unless you provide them. As many as 20% of remote workers say they feel isolated from their colleagues. This can take a toll on their emotional well-being, and that lack of social connection to coworkers will also affect their ability to collaborate.

     As a result, they may not be able to communicate as effectively with other team members. Building connections between team members let them understand each other more easily and reduce miscommunications that could lead to development mistakes and delays.

    Informal meetings via webinar platforms or video conferencing solutions can have a significant positive impact in this area. A weekly meeting gives everyone a chance to talk about what they are working on and their challenges. As a result, every team member, including freelancers, has the chance to lend their skills to a colleague’s work and help the team pull together toward achieving a common goal.

    Just as importantly, it gives remote workers a much-needed opportunity to connect with their colleagues socially and chat about things other than work. Besides the importance of team-building, this develops more of a connection between remote workers and your business. Inviting freelance developers to all meetings and social events is a great way to ensure greater inclusivity, and it can pay off if freelancers later take full-time positions at the company.

    Make Freelancers Part of the Team

    Keeping freelancers in the loop and ensuring they have the same opportunities and voice as other employees ensure they have the same level of investment in a project’s success as every other member of the team. The tools and the opportunity to coordinate with colleagues and receive feedback are critical parts of this. Following these strategies will help you integrate and manage your freelancers more effectively.

     

  • Observability Matters. But Are You Observing the Right Things? 

    Observability Matters. But Are You Observing the Right Things? 

    It’s like clockwork. Every few months, a new buzzword descends on the tech industry, and soon it’s on everyone’s lips. Take your pick from the graveyard of buzzwords past: “Big data,” “internet of everything,” “hacktivism,” “gamification.” It’s not that these terms are meaningless—just that they go from relatively obscure to ubiquitous seemingly overnight. We can add a new one to the list in the digital monitoring space: “Observability.”

    Unlike some trendy buzzwords, observability captures something that’s actually quite important about how we monitor digital systems and how current approaches differ from those of the past. So, it’s a good and useful concept. But where I take issue is with the way many analysts, technologists and vendors seem to use it. Whether or not they mean to, they often paint a far too narrow a picture of what observability is or ought to be, and that linguistic oversight can have real-world consequences. If enterprises invest in observability without understanding what, exactly, they’re observing—and what they’re not—they risk leaving themselves vulnerable to some serious blind spots. 

    What is Observability and Why Does it Matter?

    Technically, observability is an approach with the goal of understanding how a system is doing. The distinction lies in what the system is and how it is being observed. The monitoring tools of yesterday typically focused on one or more domains to identify typical and known problems. Usually, that entailed collecting metrics directly from those domains and measuring them against predefined thresholds. For example, storage levels shouldn’t exceed a certain threshold; if they do, send me an alert so I can investigate what’s happening. 

    On the other hand, observability takes a more holistic approach, examining multiple outputs of the system to infer system health. For example, suppose you were trying to gauge a car’s condition. In that case, traditional monitoring might track engine temperature or idle speed RPMs, while observability would examine things like power output, engine leaks, transmission noise, emissions and fuel efficiency to infer the car’s overall health. 

    This output or outcome-focused approach to managing performance maps well to today’s complex and distributed digital systems. Even if you wanted to, you couldn’t pull real-time metrics from every relevant component of a system when those components consist of thousands of microservices running in any number of physical servers across multiple clouds. However, the bigger problem with more antiquated monitoring models is that they only capture the specific metrics they’re designed to track. If you’re encountering a problem you’ve never seen before, your monitoring dashboard might look perfectly healthy while actual system performance is terrible. 

    Observability and APM 

    So then, observability should give you everything you need to track the health of a modern digital business, right? Well, not so fast. Because for today, people seem to use “system observability” interchangeably with “application performance monitoring,” or APM. And they are not at all the same. 

    Yes, you want an observability-based approach to tracking your application environment, and modern APM tools provide a great way to do it. But knowing the health of your application environment is not the same as knowing the health of your overall digital systems as experienced by users. And at the end of the day, if you’re not gauging performance from your users’ perspective—whether that’s customers, employees or other devices relying on your systems—then what’s the point? It’s unfortunately not uncommon to forget that the most important key performance indicator (KPI) of any digital system is the quality of its intended output or outcome. In the case of any application, the most important KPI is the user experience.

    The outputs that APM tools track do contribute to the user experience—and you want to be monitoring them. But so do many, many other things. There’s the user access itself (browsers, virtual or physical user devices loading the application). There are local, regional and global networks connecting those users to your application environment. And then, of course, there are the dozens, sometimes hundreds of third-party digital services running between and among users and applications. Problems in any link of that digital chain can seriously impact the user experience—even if your application environment itself looks healthy. 

    Observing End-to-End, from User to App and Everything in Between 

    To get the full picture of the health and performance of your digital assets, you should be tracking outputs from across the end-to-end digital service chain. That includes telemetry (logs, infra metrics, traces) from your application hosting environment. It should include actively and passively observing at the point of consumption—that is, outputs from customer browsers and worker devices. It must include active and passive monitoring of network connectivity. And it should include continuous active monitoring of all the disparate services—APIs, content delivery networks (CDNs), DNS services, cloud-based security services and every other cloud and web service that contributes to what the user is experiencing. (And by the way, you should look for independent, objective telemetry whenever possible rather than taking what your various service providers report at face value.) 

    When you approach observability from this outcome-based, holistic perspective, you can capture a real and truthful picture of the performance of your full digital business, not just pieces of it. Just as important, when you do identify a problem, you’re in a much better position to do something about it. Because now you have outputs to measure from all the many systems and services that contribute to the user’s application experience instead of just a subset of them, which means it’s much easier to zero in on which piece of the puzzle isn’t behaving the way it should. 

    A Smarter Approach to Observability

    So, should you take all the hype about observability seriously? Yes. As tech buzzwords go, you could do a lot worse. This one actually means something important. But make sure you’re keeping the big picture in mind as you do. 

    Observability that ignores the outcome begins and ends with the application environment and is nowhere near sufficient. We need to expand our sense of observability, begin with the user experience and encompass every link in the chain of the end-to-end digital business. When we do, we create a much more holistic, useful and actionable picture of the health of our digital systems. And we can make sure we’re continually monitoring digital performance in the way that matters most: As experienced by users. 

  • Policies and Procedures

    Policies and Procedures

  • Dynatrace Adds Security Gates to Advance DevSecOps Adoption

    Dynatrace Adds Security Gates to Advance DevSecOps Adoption

    Dynatrace today added a security gates capability to its observability platform to make it easier to automatically embrace DevSecOps best practices within an application delivery pipeline.

    Steve Tack, senior vice president for product management at Dynatrace, said the security gates function much the same as the quality gates that Dynatrace previously added to that platform in that each release is now also automatically assessed to ensure only secure code is being deployed.

    The Dynatrace platform now uses a Davis artificial intelligence (AI) engine to scan for vulnerabilities in application workloads in real-time and then prioritizes them based on the risk they pose, noted Tack. The goal is to make it simpler for organizations to incorporate security reviews in application development processes in a way that doesn’t necessarily require developers to become security experts, he added.

    Instead, the core DevOps platforms should be capable of identifying issues that can be remediated before an application is ever deployed in a production environment, said Tack.

    Dynatrace earlier added an ability to automatically identify the software libraries and open source packages that present the greatest security risk. The security gates capability now extends the scope of that effort to include applications as they are constructed using custom code.

    In general, most organizations are looking for ways to embrace DevSecOps best practices. The challenge is achieving that goal without unduly slowing down the rate at which applications are developed. In fact, a recent survey commissioned by Dynatrace found, on average, organizations expect to increase the frequency of their software releases by 58% over the next two years. However, nearly a quarter (22%) of respondents admit they’re often under so much pressure to meet the demand for application deployments that they must sacrifice code quality, which broadly includes security issues.

    It’s not clear to what degree security reviews will automatically be included within a quality assurance process, but Tack said the goal should be to limit human involvement in the application deployment process as much as possible. The issue many development teams encounter today is that applications are being rejected by cybersecurity teams that are reviewing applications just before they are deployed, noted Tack. As a result, developers are racing to build applications faster only to see them rejected and returned to them at the last possible moment, he added.

    In the wake of a series of high-profile software supply chain breaches, the focus on DevSecOps has increased substantially within most organizations. It’s often not precisely clear who is responsible for application security, but as DevOps platforms continue to evolve, there may come a day when security issues are routinely addressed within every DevOps workflow.

    In the meantime, there needs to be a lot more focus on bridging the divide between DevOps and security teams. Given the chronic shortage of security professionals, there’s no doubt DevOps teams need to assume more responsibility for application security. The challenge and the opportunity is finding a way to achieve that goal with the least amount of friction possible.

  • Allstacks Adds Free Dashboard to Track Software Dev Benchmarks

    Allstacks Adds Free Dashboard to Track Software Dev Benchmarks

    Value stream intelligence platform provider Allstacks today added a free live dashboard populated with anonymized data that DevOps teams can use to benchmark their own progress.

    Hersh Tapadia, Allstacks co-founder and CEO, said the company is making this data available to make it easier for DevOps teams to uncover bottlenecks in their software development processes.

    As part of that effort, the dashboard includes pre-configured benchmarks for the following:

    How many days per week do benchmark teams write code?
    What percentage of issues are planned versus unplanned for benchmark teams?
    What are the cycle times per issue type for benchmark teams?
    What types of code do benchmark companies produce?
    What is the average commit size for benchmark customers?

    Allstacks

    Allstacks has committed to making 12 months of data publicly available on the dashboard and said it will update that data on an ongoing basis. Allstacks customers, however, can also access five years of data to compare historical trends.

    Tapadia said Allstacks plans to add additional benchmarks to a dashboard that can collect data via the various application programming interfaces (APIs) that most DevOps tools now routinely provide. The overall goal is to increase transparency into software development processes, he said.

    Allstacks’ value stream intelligence platform uses machine learning algorithms and artificial intelligence (AI) models to identify projects that are at risk of not meeting delivery goals. That data is then used to analyze the impact those missed deadlines are likely to have on various business objectives.

    Value stream management platforms automatically take technical metrics, gathered via a DevOps process, and match them to a set of key performance indicators (KPIs) defined by business leaders. The challenge many organizations still face is making sure they have the tools in place to collect the appropriate technical metrics and then define the KPIs that truly matter to the business. Once those metrics are gathered and KPIs established, organizations are then able to apply advanced analytics to the massive amounts of DevOps data they collect.

    The concept of value stream management traces its lineage back to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved from being a craft to a process that is highly automated using DevOps best practices, an appreciation for the value of monitoring the impact of missed software development deadlines on the business has grown as organizations realize how dependent they are on software.

    As a result, more organizations realize there is a clear disconnect between their business goals and development processes, noted Tapadia. Business leaders are especially anxious to understand how a software development project delay might impact future revenue projections. Rather than being a set of tools employed mainly by IT leaders to track software development projects, value stream management platforms make it possible for other stakeholders to track KPIs spanning multiple software development projects. It then becomes easier to make informed decisions about how to reassign resources across various projects as different bottlenecks are encountered.

    It may be a while before organizations achieve that level of transparency into their software development processes, but as software continues to ‘eat the world,’ it’s only a matter of time before value stream management becomes a required set of DevOps tools for every organization.

  • Grafana Labs Expands into Incident Management Realm

    Grafana Labs Expands into Incident Management Realm

    During its online ObservabilityCON 2021 conference, Grafana Labs this week previewed an incident management platform in addition to making available an on-premises edition of its distributed tracing tool.

    Tom Wilkie, vice president of product for Grafana Labs, said the Grafana OnCall incident management platform is a natural extension of the observability tools the company already provides using the widely employed open source Grafana dashboard. The platform, which is expected to be generally available in 2022, is based on software Grafana Labs gained by acquiring Amixr earlier this year.

    Grafana OnCall unifies all the alerts created by Grafana, Prometheus and the Alertmanager tool the Prometheus community created to streamline the number of alerts generated by the platform. The goal is to reduce the alert fatigue a DevOps team might experience when dealing with an IT issue that can be traced back to a single root cause, noted Wilkie.

    Grafana

    At the same time, Grafana Labs made Grafana Enterprise Traces available for on-premises IT environments. It is based on Grafana Tempo, a cloud service that makes it possible to store and then analyze distributed traces using inexpensive object storage resources. The latest version of the core open source Tempo project has also been updated to add service graphs and the ability to search recent traces.

    Grafana Labs this week also updated Loki, an open source log management platform, to add support for out-of-order log lines, custom log retention policies per log stream and per tenant and a deletion API that makes it easy to scrub log data. Version 2.4 of Loki also adds additional high-availability capabilities.

    Other updates to the Grafana Labs platform include support for recorded queries, a set of pre-built dashboards that enable users to quickly drill into their Prometheus metrics data, the ability to consume metrics from the AWS CloudWatch service provided by Amazon Web Services (AWS), improvements to its ability to monitor Kubernetes clusters and updates to the open source load testing tool the company gained by acquiring k6 last year.

    Grafana Labs is also committing to expanding its integration with Microsoft Azure cloud service alongside its integrations with AWS, noted Wilkie.

    While competition among providers of observability platforms is already fierce, Wilkie said an observability platform based on an open source dashboard that can already collect data from more than 100 sources provides a unique advantage. At the core of the Grafana Labs platform is a centralized framework for collecting data generated primarily by the open source Prometheus monitoring platform being developed under the auspices of the Cloud Native Computing Foundation (CNCF).

    While Prometheus is used most often in Kubernetes environments, it is starting to gain traction in monolithic application environments as well; it provides an open source approach to defining a de facto standard for collecting metrics and other data that can be consumed by an observability platform.

    It’s not clear yet to what degree IT teams are distinguishing between monitoring and observability. Monitoring focuses on predefined metrics to identify when a specific platform or application is performing within expectations. Observability combines metrics, logs and traces to instrument applications in a way that makes it simpler to troubleshoot issues without relying solely on a limited set of metrics that are pre-defined and monitor a specific process or function.

    Regardless of whether IT teams view observability as being distinct from monitoring, it’s clear that the ability to manage IT environments is improving at a rapid rate. The challenge, of course, is the IT environment itself is becoming more complex with each passing day.

  • Automated Refactoring with Moderne

    Automated Refactoring with Moderne

    Jonathan Schneider and Olga Kundzich are co-founders of Moderne, a Seattle-based startup. Moderne received $4.7 million in seed funding in July 2021 to commercialize OpenRewrite, an open source automated refactoring tool for code (initially Java) that Schneider started while at Netflix. Moderne’s technology reduces the tedium and time it takes for software remediation; a big problem in today’s world of cloud-native development. The video is below, followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    Alan Shimel: Hey, everyone. Welcome to another segment of TechStrong TV. We have a new company to detail for you, and we have two cofounders here to tell you all about it. It’s a great open source story as well. Let me introduce you to – and I’m gonna do my best not to mess it up – Olga Kundzich, Kundzich, Kundzich – three times the charm – and Jonathan Schneider. I think I got that one on the first try. Olga, Jonathan, welcome to TechStrong TV. 

    Olga Kundzich: Great to be here. 

    Jonathan Schneider: Thanks. It’s good to be here. 

    Alan Shimel: Thank you. So the only rules is only one of you can talk at a time, but both of you can talk as much as you’d like. But why don’t we start off with maybe a little bit about each of you. Olga, if you don’t mind, why don’t you go first and maybe share with the audience a little bit of your background and how you came to be here today. 

    Olga Kundzich: Great. So my background, I was working at Pivotal on a Spinnaker continuous delivery solution, and that’s where Jonathan and I had met. We worked together there for about a year and a half. Prior to that, I worked at EMC in engineering for, in different functions for a number of years. So when we were working together on Spinnaker, we talked to a lot of people in the industry. There was a lot of interest around that product, and kind of we realized that everyone had sort of the same problem. We would start a conversation about some old feature, and it will come back to, well, all my application is still stuck on this old, aging framework, and let me talk to you in a year when I migrate all of this back.

    So and the problems were highly repeatable and kind of same framework, same third-party vulnerabilities, same libraries, APIs, so after reflecting on this we realized that this is really not a coincidence. It’s a consequence of modern application development practices. Our software right now is 90 percent third-party dependencies, open source, APIs, so the problem’s kind of highly repeatable. And that’s kind of led, what led us to, back to technology that Jonathan developed earlier at his time with Netflix and kind of take it, develop a lot of more functionality into that sort of large-scale distributive factoring that will help us solve these type of problems, the framework migrations, API migrations, CVE patching that cross all of these open-source and third-party dependencies. 

    And I will let Jonathan speak about his background and a little bit on the open-source framework.

    Jonathan Schneider: Yeah, so Netflix had this engineering culture called freedom and responsibility, so product engineers were sort of, had the freedom to do whatever they wanted really. They could use their, a different build tool, they could use their particular Java style, they could use whatever libraries they wanted, and so forth. And so as a central team, if you’re on an engineering productivity team or you’re on a platform team and you’re trying to effect some change inside the organization, we couldn’t put up gates in front of product engineers that would, say, break their build if they didn’t comply with a certain thing. Instead, you tried to build tools that would help bring them along on a journey with you, and I kept hearing the same thing over and over again from engineers which is, hey, I got a lot on my plate. Happy to move forward to this new pattern that you want to see, if you do it for me. If you just do the work for me, I’m happy to commit it. 

    Alan Shimel: Nice of them. 

    Jonathan Schneider: And of course, you know, you think there’s two of us and 700 of them, and that doesn’t scale super well. Right? So that’s where we started working on a way of actually automating the source code transformation. When we developed that technology, one of the consequences of that freedom and responsibility is that there was not a consistent style of the code or consistent patterns, necessarily. So that refactorization we built had to make transformations that were, looked like they were a developer writing in that code base stylistically consistent, hundred percent accurate changes. And so we got some interesting results out of that, so when Olga and I were working together and you would hear, “Oh, I’m still stuck on Spring Boot 1 and I’m trying to get to Spring Boot 2,” or, “I’m stuck on JUnit 4. I’m trying to get to 5,” we just found another application of this at a larger level in a highly repeatable problem space. 

    Alan Shimel: Fair enough. You know what, I’ve spent the last 20 plus years talking to founders. I’ve founded my own companies. This is what happens. You see a real problem. Right? See a real-world problem. There’s got to be a better way we could solve it. Sometimes you find out solving that problem is not as easy as you thought. Sometimes it is, very rarely. But you work through it and that’s what startups are all about. In your case, though, I mean, look, Spinnaker, which is now part of CDF, right, was managed by CDF, but Google, Netflix were instrumental in the development of Spinnaker. But Spinnaker is an open source tool, and you guys went with an open source route in what you’ve developed. Why don’t we talk about that a little bit? 

    Jonathan Schneider: Sure, yeah. There’s really two parts to our product offering. There’s OpenRewrite, which is GitHub slash OpenRewrite. OpenRewrite is that core refactoring technology we’ve been talking about that can make stylistic automatic and consistent changes to a code base. On OpenRewrite we built recipes, so we have a recipe to migrate you from Spring Boot 1 to 2, from JUnit 4 to 5, to do code cleanup things, to do security vulnerability fixes. We want those recipes to always be Apache licensed and open source. Framework authors are going to develop the recipe, so the Spring team will develop the recipe that will move you from Spring Boot 2 to 3, or the Quarkus team at IBM or Red Hat would develop the recipe that’d move you from one version to another.

    What Moderne does commercially is we take those recipes and we run them at massive scale, so I could take that recipe and run them against tens or hundreds of millions of lines of code, and you can see that, the impact of that recipe running against your whole organization’s code base. 

    Alan Shimel: Fair. And so you mention – how did – it’s not Modern. It’s Moderne. Correct? 

    Jonathan Schneider: Yeah, we call it Moderne. Yeah.

    Alan Shimel: Moderne. So that’s the name of the company.

    Jonathan Schneider: It’s the name of the company, yeah. 

    Alan Shimel: And OpenRewrite is the open source aspect of it or –

    Jonathan Schneider: That’s right. 

    Alan Shimel: – owner of the solution. So let’s get into the mind of the entrepreneur here a little bit, Olga. Having worked at Pivotal and EMC for years before this, you saw this issue. You saw this problem. There’s got to be a solution. When did you say, you know what, this is something worthy of starting a company, right? When I was starting companies, one of the big questions is, is this a feature or a product? Right? Is it just a feature of someone else’s product, or is it truly a product in and of itself? And that makes a big difference in, obviously in what you’re building and what your aims and all of that. Olga, I’d like to hear from you. Feature, product, how did – what was kind of your thought process in saying, you know what, this could be its own company?

    Olga Kundzich: I think this, something like this is essential for managing modern cloud-native applications. These are becoming, the applications sort of become a glue code teaching all of these third-party components. They evolve and change at their own pace, and developers really right now are just restitching those things back together, upgrading CVs, upgrading versions, and it takes a really significant amount of time just to – sort of anecdotally we hear from people that 20 to 30 percent of their time, engineering time, is just now dedicated to these tedious migrations. So if we can automate this, we can unlock innovation, productivity of engineering organizations, and help a lot of businesses actually innovate.

    Alan Shimel: Got it. Jonathan, what about from your end? Well, let me ask you both. Is this your first time starting a company? 

    Jonathan Schneider: It’s first time starting a company, yeah. I think it’s real special to me. I think one thing I love about this business is that we’re really after helping organizations fix their code, and our outcome and our future success is tied directly to how much code we’re able to fix, how much help we’re able to provide. We’re not about reporting and saying like, you know, here’s the problems that you, engineering team, need to fix. When we partner with an organization, we’re kind of in the trenches with them getting these issues off their plate.

    We talked to one organization recently – and this is why I think it’s a product and not a feature. We talked to one organization recently and they say we just look at our top ten issues reported by a series of static analysis tools they have in-house, and it says, well, it’s gonna, these tools estimate it’ll take 1,700 developer days to fix these top ten issues. So that’s like 4.8 years’ worth of developer time to fix those top ten issues that they have, and those aren’t false positives. Those are just literally top ten critical problems they have right now. So we developed recipes for a lot of those, and their engineers said, you know, “We estimate it would take us five days with these recipes to apply that change and be done with it.”

    When I think about 1,700 developer days or 4.8 years of time, what that really means to me is infinity, or like it means that the engineering team is never going to get through that backlog of issues. Five days seems like it is possible, and that’s, there’s this line we have, the, basically software grows until it can no longer be maintained, and I think our business is in keeping that software in a maintainable state so that the business can continue to innovate and thrive. 

    Alan Shimel: Absolutely. So companies launch now – we didn’t even mention the website. Shame on –

    Jonathan Schneider: Yeah.

    Alan Shimel: What’s the website? 

    Jonathan Schneider: Yeah, so the website is moderne.io, so it’s modern with an E.

    Alan Shimel: Can you spell that, Jonathan? M-O- –

    Jonathan Schneider: Yeah, it’s M-O-D-E-R-N-E, so modern with an E, dot I-O.

    Alan Shimel: Dot I-O.

    Jonathan Schneider: Yep, that’s right. We do have a restricted beta going on right now that you can just sign up for that on that website, and we’ll do an invite to you and you can see how we can apply these recipes across tens of millions of lines of code. 

    Alan Shimel: Absolutely. Are you working with CDF and the Spinnaker community?

    Jonathan Schneider: We’re really in an adjacent product space now. I think there’s a lot of value to operational automation, what Spinnaker is doing, what different APM vendors are doing. I think we were working in that and we saw just an adjacent pain point that we just decided to go after instead. 

    Alan Shimel: Good stuff. Well, guys, I want to wish you nothing but a lot of success with this. It’s always, you know, I gotta be honest with you. I always enjoy interviewing new companies coming out of stealth and beta, first-time entrepreneurs, ’cause you make the world go around. And good luck. Keep us posted. Come back on and tell us more as you, as the story continues to unfold here. 

    Jonathan Schneider: Yeah, look forward to talking again soon. 

    Alan Shimel: All right. 

    Olga Kundzich: Thank you.

    Alan Shimel: Jonathan and Olga from Moderne, M-O-D-E-R-N-E, dot I-O, here on TechStrong TV. We’re gonna take a break. We’ll be right back.

    [End of Audio] 

  • The Need for Agile, Adaptable IT Infrastructure

    The Need for Agile, Adaptable IT Infrastructure

    Through the adoption of Agile concepts and new best practices such as automated testing, organizations can move beyond the innovation curve and bolster their IT infrastructure. In fact, the need to build agile and resilient IT infrastructure has become increasingly pertinent over the past 18 months. 

    From remote working and managing the diverse needs of employees in remote locations to the growing rates of cybercrime, the move from the physical world to the virtual one has seriously impacted the ability of organizations to operate. It comes as no surprise that business leaders are increasingly investing more in new tools and technologies to improve their IT infrastructure, transform operations and drive business value. 

    That said, it still remains relatively rare for enterprises to wholly adopt Agile approaches and techniques, despite the fact that doing so can help improve the efficiency at which goods and services hit the market. The fact is that many technology companies still do not use Agile as it is difficult to implement at scale. In addition, Agile transformation demands a cultural change, which can often take time. 

    Nevertheless, sooner or later, Agile IT will need to be implemented across businesses in various industry sectors, as well as across all branches of an organization. Our experience has been that Agile transformation will help your business grow and succeed. 

    What is Agile IT? 

    Agile is a philosophy—a mindset that can be applied to improve the provisioning, management and operation of digital infrastructure. Agile promotes business-led development, whereby a product owner and software development team collaborate as a single entity to deliver tasks that are prioritized based on business value. These tasks are also delivered over a short timeframe, such as via two-week sprints. 

    Essentially, your infrastructure is far more likely to be both secure and resilient if Agile concepts are implemented throughout the software engineering process. As a result, new digital products can be delivered to customers more quickly. For example, Agile ways of working include making small, iterative changes to deliver high-quality results with speed. You can also spin up infrastructure when needed, which keeps the cost of innovation down. 

    The Differences Between Agile and Traditional IT Infrastructure? 

    Infrastructure agility is best achieved using modern solutions such as cloud technology. This significantly differs from the traditional approach of having on-premises infrastructure, which cannot be scaled up or down as needed. In fact, on-premises solutions often require extensive upfront capital, while investing in cloud resources works on a pay-as-you-go model to deliver flexibility and elasticity for strategic needs. 

    The conflict between adaptive software methods and predictive methods is another significant difference between these approaches. Development teams follow a comprehensive plan in traditional waterfall approaches, and any changes must go through stringent change control management. Agile requirements, on the other hand, require flexibility, allowing teams to adjust to changes as soon as they occur. This method is suitable for smaller projects that must be performed quickly and efficiently. 

    Benefits of Implementing Flexible IT Infrastructure

    The advantages of having Agile IT infrastructure are numerous. In fact, the adoption of Agile methods not only promotes business growth but is also a great way to reduce costs and improve team performance. By working in sprints, teams can turn around features more often and nurture their value throughout the business. Agile transformation also enables organizations to offer new products or solutions to customers faster, gain early feedback and make changes if necessary, thus avoiding error from the very beginning. 

    Cost optimization is another benefit to consider. With Agile infrastructure housed in the public cloud, IT leaders can expand or decommission resources based on consumer demand. Cloud companies’ pay-as-you-go strategy also ensures that costs are kept to a minimum viable level. For example, maximum limitations can be set for the scaling out of resources. Most importantly, agile working methods eliminate the need for substantial upfront investments, resulting in a higher return on investment (ROI). 

    How to Achieve Agility

    The benefits of Agile transformation are clear; however, the journey to achieving this can take time. First and foremost, becoming Agile requires a clear understanding of what it means and why it is important for your business’ competitive context. Once the ‘what’ and ‘why’ are defined, the ‘how’ becomes easy. The three core steps to achieving this agility are: 

    1. Implementing new methods
      Instead of trying to rework existing IT management tasks and procedures, it is often better to think of new ones as part of the Agile journey. This will ensure that your system’s performance and availability are in line with your core goals. 
    2. Investing in the right tools
      Agile is all about delivering smaller outcomes quickly. To achieve this speed, automating key stages of the software development process is key. There are a host of tools available to undertake this automation, including hybrid cloud solutions that can seamlessly switch between the public and private cloud. A careful selection of the tools that best fit your needs and the correct implementation of these throughout the organization is paramount to achieving success. 
    3. Changing the culture
      To become an agile business, the entire organization requires a cultural change—from how the business discovers a problem to how that problem is resolved by technology teams and monitored in production to enable a faster feedback loop. At every stage of the process, team members need to perform tasks differently, which often requires training, buy-in from the wider team and a collaborative approach. 

    Investment in Agile IT is a smart decision for business leaders hoping to transform their operations, ensure resilience and drive business value. By choosing infrastructure that caters to these needs, you can save money and ensure confidence at critical moments.