Tag: it

  • Dell Extends Reach of Managed IT Infrastructure Service Portfolio

    Dell Extends Reach of Managed IT Infrastructure Service Portfolio

    Dell Technologies today expanded the scope of its APEX managed cloud offerings to include integration with the Microsoft Arc hybrid cloud computing framework. In addition, Dell is fulfilling a commitment to deliver block and file storage services on the Microsoft Azure and Amazon Web Services (AWS) cloud platforms.

    The announcements were made at the Dell Technologies World conference where Dell also announced it is extending existing support for managed APEX instances of VMware that include storage services.

    Dell is also making available a bare metal edition of the service, dubbed Dell APEX Compute, that provides IT teams with the option to deploy any virtual machine or Kubernetes cluster of their choice.

    Finally, Dell is also making available an instance of an APEX managed service that supports Red Hat OpenShift, an application development and deployment platform based on Kubernetes.

    Overall, Dell is promising that IT teams will soon be able to move data seamlessly between on-premises environments and Dell APEX Block Storage for Public Cloud. This capability will first be available for AWS and, later this year, Microsoft Azure. As part of that effort, Dell is also launching Dell Navigator, a software-as-a-service (SaaS) platform for managing services such as data replication that includes an edition for Kubernetes clusters. In addition, Dell announced a partnership with Databricks to integrate on-premises storage systems from Dell with the Databricks Lakehouse Platform cloud service.

    Caitlyn Gordon, vice president of multi-cloud product management for Dell Technologies, also claimed that file services running on public clouds using Dell software will be four times faster processing writes than any rival offering.

    The Dell APEX portfolio, at its core, is based on a suite of fully integrated turnkey servers, storage systems, and now, PCs, all managed by Dell on behalf of organizations that subscribe to the APEX service. Dell is now extending the reach of those services into cloud computing environments to make it simpler to deploy workloads everywhere from the network edge to the cloud, said Gordon.

    Most IT organizations today are managing multiple clouds by default. The Dell APEX services simplify the management of those environments by employing the same type of operating model to manage on-premises IT environments, she added.

    Dell is betting that as organizations deploy more complex cloud-native applications, many of them will opt to rely more on external services to manage the underlying infrastructure those applications depend upon. That approach is intended to enable IT organizations to devote more resources to building and deploying applications.

    It’s not clear whether organizations will prefer to rely on Dell to manage their IT, continue to manage it themselves or rely on a third-party IT services provider. Of course, many internal IT organizations are not inclined to cede control over IT infrastructure and applications to a single IT vendor, especially if they use IT infrastructure that has been provided by multiple vendors.

    Regardless of approach, there are now more organizations that prefer to treat IT as an operational expense. In effect, Dell is enabling a cloud operating model to be applied to all IT infrastructure, regardless of where applications are deployed.

  • Why We Need to Rethink Data Pipelines

    Why We Need to Rethink Data Pipelines

    Data is the fuel that powers modern business. But as demand for data surges, so does the pressure on data leaders and practitioners to deliver it. Businesses need resilient data pipelines that deliver critical insight for real-time decision-making to users on demand. However, against the backdrop of today’s chaotic modern data ecosystems, this is much easier said than done.

    DevOps teams are struggling with a complex combination of legacy and diverse technology systems across multiple environments. The resulting siloed systems and an ever-shifting data supply chain cause significant data integration friction. This friction keeps businesses from creating seamless and resilient pipelines to drive digital transformation and other business outcomes. Businesses need a better way to take the pressure off data leaders and DataOps practitioners and enable line-of-business teams to do more of the “last mile” data collection and analysis themselves. To achieve this, they need a unified, end-to-end platform designed to build resilient pipelines.

    Data Demand Sparks Friction

    The acceleration of digital transformation has created a demand for data that far exceeds supply. This has become especially true as competitive advantage gets harder to carve out and worrying macroeconomic headwinds gather. In today’s climate, all areas of the business are demanding data, but it’s hard to meet every request all the time.

    Research that polled data leaders and practitioners shows nearly half (48%) of admin and operations and customer service departments request data at least weekly, followed closely by accounting and finance (44%), IT and digital (43%) and sales and marketing teams (40%). And the strain is showing. Over half (59%) of data leaders said changing priorities have created significant data supply chain challenges.

    The problem is one not just of capacity but complexity. Building pipelines from source to destination requires rules to integrate, transform and process data. But when data is siloed across cloud, legacy and mainframe systems and stored in inconsistent formats, creating bespoke data pipelines to fulfill departmental requests is a huge challenge.

    Legacy systems also bring another challenge. Over half of data leaders say it’s so difficult to unlock data from legacy systems like mainframes that they simply don’t bother. That will ultimately undermine the value of the cloud analytics tools that many business leaders see as a single source of truth for decision-making–especially as legacy systems often hold decades of vital business insights.

    This patchwork approach creates extra toil for DevOps, DataOps and technical teams and means that over two-thirds (68%) of data leaders said they are being prevented from delivering data at the speed the business needs.

    The Scourge of Broken Pipelines

    For many organizations, building pipelines is also a labor-intensive job requiring a high degree of manual effort to produce hand-coded, one-off solutions. The resulting pipelines are brittle and vulnerable to being disrupted whenever there is a shift in the environment–such as adding new data sources. In fact, two-fifths (39%) of data leaders admit their pipelines crack at the first sign of trouble, and 87% have experienced a break at least once a year. More than one in 10 say it happens at least once a day.

    The most significant cause of breakages is due to bugs and errors being introduced during a change (44%) while infrastructure changes such as moving to a new cloud (33%) and credentials altering or expiring (31%) are also creating disruption. These broken pipelines immediately impact the corporate bottom line. They also force technical teams into a vicious cycle of firefighting. Data engineers spend, on average, almost a third (31%) of their time troubleshooting and recoding broken pipelines–time that could be better spent on value-adding tasks.

    But the negative impacts aren’t only felt operationally. The breakage of any pipeline can also lead to bad decision-making. For example, a supply chain director working with old data may over- or under-order goods or a financial trader making stock picks on out-of-date intel may lose money for a client.

    Unleash the Power of Data

    For organizations looking to overcome these challenges, the first goal is to reduce the workload on DevOps, DataOps and technical data teams by empowering business units and end users to do more. Research shows that 70% of technical data leaders are responsible for the last mile of data collection and analysis while 86% of them would prefer lines of business teams, such as marketing or finance, to be empowered to do this independently. However, this can only become a reality if organizations invest in the right data integration platform. It must be able to build, run, monitor and manage smart data pipelines at scale from a single console–across all cloud and on-premises environments. And it must be able to deliver resilient pipelines built to withstand continuous change.

    Only by eliminating data integration friction and enabling self-service analytics for lines of business can organizations accelerate digital transformation. Doing so will unleash the power of data across the enterprise and reduce the burden of overworked data leaders and practitioners.

  • Don’t Make Big Tech’s Mistakes: Build Leaner IT Teams Instead

    Don’t Make Big Tech’s Mistakes: Build Leaner IT Teams Instead

    One of the biggest narratives in the U.S. concerning the current wave of tech layoffs is the fact that ‘traditional’ sectors have a prime opportunity to snap up new tech teams and IT talent. This has always been a significant challenge for sectors such as banks, insurance and manufacturing that compete with big tech for talent. In 2022, a majority of CEOs (71%) identified skills and labor shortages to be that year’s biggest business disrupter.

    And they were right to be worried. According to Salesforce, three in four workers do not have the digital skills needed by businesses to prepare for the future of work. The temptation in this environment for many traditional organizations is to enter the labor market to build larger tech teams to help drive their modernization programs. However, this may be a mistake.

    Building large, expensive, bloated tech and IT teams is not always the answer. It’s critical that traditional companies learn this lesson from big tech.

    Instead, traditional organizations should consider other avenues to drive their digital transformation ambitions with their lean resources. What does this look like?

    What is the Real Challenge you are Trying to Solve?

    Since COVID-19 hit, U.S. companies have been forced to reevaluate how they work, with remote working becoming commonplace–even for companies who couldn’t imagine themselves working remotely.

    And the challenges have grown as U.S. businesses seek growth to recover lost gains from the last few years. Evanta’s 2022 CIO Leadership Perspectives study found that CIOs rate data and analytics as their second top priority within the IT function. It is clear that business leaders see advancing organizational use of data, analytics and automation as key to reaching enterprise objectives.

    For many organizations, the biggest challenge they face is the unprecedented amount of data generated. Critically, more than 80% of all new data is unstructured and messy. This makes it difficult for data-driven companies to accurately review, gather, analyze and rely on what is mission-critical information.

    Traditional industries such as health care, banking, insurance or the public sector, have even larger concerns because data is increasingly critical to how they build value and deliver services for customers. So, it is important for their IT teams to create a single source of truth and data governance framework across their organizations to ensure the right people and senior leaders have the most accurate information to make smarter decisions.

    For instance, in the manufacturing industry, no-code database platforms can be leveraged to structure daily operational data and visualize insights through digital dashboards for quality assurance, continuous improvement and health safety.

    Additionally, at Baserow, we work with treasury customers at some of the biggest international banks that use no-code platforms to keep track of local legislation around the world by centralizing information in real-time databases available to relevant teams, including compliance.

    Modern organizations depend on their IT teams to accomplish a lot of their goals. So, it is important to provide them with the tools to focus on more complex development projects. No-code tools free your non-technical teams to address their pressing needs themselves without having to wait for budget or resource availability in the IT department.

    Have you Also Considered Upskilling Your Current Team?

    We know from the Salesforce survey that the vast majority of U.S. workers lack the digital skills to support their organizations’ ambitions and needs. This suggests that there is a wider issue within most companies at large. Do businesses need to prioritize upskilling their current team instead?

    A U.S. Gallup report found that 72% of workers are overwhelmingly interested in pursuing additional digital training to prepare them for an increasingly digitilized workplace. Is there room for no-code technologies to supplement the digital capabilities within companies?

    Enterprises are already expanding the responsibilities of application development outside their IT teams as well as increasing the productivity of their existing IT resources by automating and abstracting repetitive developer tasks. Gartner predicted that by 2025, 70% of apps will employ low-code/no-code technology. This trend aligns neatly with the business needs, such as the development of organization-specific applications and tools, because every business’s requirements are different.

    Furthermore, no-code/low-code technology enables companies to drive innovation and shorten the idea-to-market cycle times. The technology’s pre-built components make it easier for end-users and workers to intuitively assemble the templates that solve their complex needs.

    In Conclusion

    U.S. companies that need to fill the IT skills gap should consider how technology can be leveraged to boost productivity and accelerate the speed of innovation while accepting that new technical resources will continue to be expensive and scarce.

    These organizations are better off taking the lead in the democratization of IT within their teams. Only then can they keep up with the speed and agility required in today´s competitive environment.

  • Low-Code Should be Worried About ChatGPT

    Low-Code Should be Worried About ChatGPT

    Is ChatGPT the technology revolution that will save the world, or the Pandora’s Box that will eventually destroy it? How about neither? Putting these two extremes aside, a more rational concern is whether ChatGPT will steal your job, especially if you work in software development.

    Is this a fair concern? Conversations like this are nothing new. New technologies always go through this cycle; starting with intrigue then moving onto fear and resentment until eventually being accepted and embraced as the new normal.
    ChatGPT and other natural language AIs are undoubtedly exciting new trends with huge potential. One area of ChatGPT’s potential that has largely been overlooked is how it can democratize software development. Should low-code/no-code providers be worried about this?

    Delivering the Low-Code Promise

    Low code has long promised to democratize software development by providing a way for non-coders to develop applications themselves. This “democratization of IT” promises a new wave of innovation by enabling organizations to create new processes without the new to engage with IT. While low-code has already achieved some great things when and where it has been implemented, the amount of change it can deliver is fundamentally limited by the developer’s choices. The developer still chooses which aspects of the application can be configured by the user, so the user still has no fundamental access to the code. While this has been low-code’s strength (since users cannot damage the underlying code if they can’t access it), users are still beholden to developers to do anything significant. ChatGPT could allow users to make more significant changes to applications, potentially enabling organizations to achieve far more than with low-code and in half the time.

    Software Development is Just the Start

    ChatGPT can achieve more than helping non-developers build the applications they need. If you think about the most common reason for an IT project failure, it is rarely down to poor delivery or mismanagement alone. Most IT projects fail because they do not deliver the outcomes that users want. This happens because of a communication breakdown between IT and end users. On one hand, users fail to convey exactly what they want and IT fails to ask the right questions to find out. The requirements (i.e., the intended outcomes) get lost in translation because technical and non-technical people simply speak different languages.

    In a scenario where the message is too often lost in translation, ChatGPT can serve as the interpreter between those who build and maintain IT and the wider staff who use it day-to-day. ChatGPT can bridge the gap because users won’t need technical skills to realize the changes they want.

    Always Start with the Business Case

    Delivering change in an organization is fraught with challenges and uncertainty. Like any project, it is important to start with the fundamentals of what you’re trying to achieve, not the technology you want to use. No matter how much you want to use ChatGPT, you must start by defining the outcomes you want to achieve and working backward from there. How you achieve these outcomes is a technical decision that comes much later. If one of your questions is to enable change to happen faster and to be more adaptive to the company’s needs, then ChatGPT may well form part of the answer. Just remember to define the problem first, build the business case and then evaluate the various solutions to achieve those objectives. Don’t get carried away by the hype.

    ChatGPT Needs Room to Flourish Outside of IT

    ChatGPT has the potential to be the bridge between technical and non-technical users in every organization. It can reduce the gulf between these radically different types of people to speed up change in the organization and deliver better outcomes for all. But it is crucial for technologies like ChatGPT to sit within the domains where they will have the best chance to flourish. In what might sound like a controversial statement from someone in the IT sector, I believe that, like low-code, ChatGPT must sit outside of the technical domain. ChatGPT needs to move out of the IT sector where it was born to reach its full potential. The question is, is IT ready to let it go?

    Image via Unsplash

  • Day in the Life of a Chief Developer Experience Officer (CDXO)

    Day in the Life of a Chief Developer Experience Officer (CDXO)

    Developer experience (DX) has become essential to modern enterprise software development. As more companies become software companies, more are opening up their software both for internal reuse and externalized consumption. As part of this process, making developer-facing tools consumable and friction-free becomes more necessary to both perform well and stand out in the market.

    To oversee developer experience quality within an organization, an entire new role is beginning to emerge — the chief developer experience officer (CDXO). A CDXO is in charge of ensuring the intuitiveness of developer-facing toolsets and being an advocate for engineering needs. Such a focus could improve internal platform usability, like within platform engineering initiatives. Or, it may involve improving the developer experience for public or partner APIs through quality documentation, SDKs, libraries, forums, tutorials and more. A CDXO might interface with many departments to monitor and improve DX across the organization.

    Since the role is in its very early stages, few CDXOs exist. But I tracked down a few to gather insights on the emerging position—I had the unique opportunity to sync with Alessandro Cauduro, chief developer experience officer at Azion and Ivan Burazin, chief developer experience officer at Infobip. They both shared some fantastic insights on why DX is so important these days and what qualities make a good developer experience leader. Below, I’ll distill their wisdom and take a peek into the life of a CDXO.

    Why DX is Important

    First, it’s good to reiterate that developer experience is increasingly important for several reasons. Organizations want to build and ship applications faster and more securely. Yet, it can be difficult for programmers to keep up with new technology trends. “Technology is always changing, and developers are always having to try new things,” said Cauduro. “As a result, you rarely become an expert on a single platform.”

    Developer experience helps you get up and running quickly with new tools. The mindset is similar to user experience (UX) but more applicable to different interaction points like APIs, CLIs, SDKs, VSCode plugins, libraries or other developer-facing technologies. Improving usability for these packages helps ease the daily grind, increases productivity and can be a competitive advantage, said Cauduro. He added that a benchmark of great developer experience is when you don’t even have to read the documentation to understand what you have to do.

    “I think that developers are the lifeblood of innovation,” said Burazin. “They are the ones creating solutions and implementing transformative technologies. Yet, they are often let down when it comes to the tools they use to achieve this innovation, so providing a great developer experience is paramount if we want to foster that innovation as much as possible.”

    CDXO Roles and Activities

    So, what does a day in the life of a CDXO officer look like? What are some of their roles and responsibilities? According to Cauduro, the overarching goal is to put himself in the developer’s shoes—he constantly thinks about common developer workflows and considers how to create a seamless experience throughout the entire development life cycle.

    Next is spreading awareness throughout the company about DX principles and how to increase DX within their offerings. A CDXO will likely answer directly to executive leadership but might interface with many departments. A CDXO may direct teams to construct developer-specific tools, like libraries, documentation, SDKs and self-service environments. “DX is a mindset,” said Cauduro. “The whole company needs to be engaged in it.”

    “As with any C-level position, your job is on the one hand to make your team’s life easier in any way you can,” said Burazin. “And on the other to convey the developers’ issues or ideas to the company in hopes of nudging the company in the correct direction.”

    A CDXO may also oversee developer relations efforts, which focus on fostering a developer community. There are many ways to interface with partners and clients to exchange ideas on how to build against the platform, Cauduro explained. This includes promoting open source projects, encouraging user meetings or interacting on Discord and forums to provide answers to community questions.

    Qualities That Make a Good CDXO

    The CDXO position isn’t for everyone. So, what personality traits make a good candidate for the role? Here are some of the necessary qualifications for the type of work:

    • Experience as a programmer. A CDXO should have past experience as a professional developer. Engineering knowledge will help them understand the persona and empathize with their needs.
    • Leadership qualities. The role also requires leadership expertise, as a CDXO must have the ability to coordinate and influence many different areas of the company.
    • Creativity. Since the role is pretty nascent without a written path, it will require creativity. Having the ability to experiment, accept feedback and reiterate is also important, said Cauduro.
    • Empathy. Communication skills and empathy also go a long way. “Deep engineering knowledge crossed with great people skills is the mix you would need for such a task,” said Burazin.

    Developer Experience in Practice

    At Azion, Cauduro is interested in how its tools can help developers move solutions from the cloud to the edge more seamlessly. To that end, they’ve found that Jamstack fits well with the needs of edge computing. Thus, some of his efforts focus on making the process of deploying a Jamstack app to the edge as seamless as possible for engineers.

    While DX efforts have helped address development bottlenecks at Azion, the role of CDXO may not be necessary within all companies, admitted Cauduro. It’s more of a fit for API-first or SaaS companies that target developers as a primary consumer base. That being said, other companies can still benefit from a developer experience focus to enhance their internal IT platforms.

    At InfoBip, Burazin explained that developer experience efforts center around helping external developers consume the InfoBip API, an API for all communication channels, such as SMS, voice, WebRTC and more. Sitting under the CTO, Burazin helps run three teams and DX has its own department. Impressively, he reports revenue on self-service APIs has increased fivefold in the past two years.

    Burazin, also the co-founder of Codeanywhere, explained that his role is to “convey the worries or needs of the developer customers to management and help steer the ship in the right direction.” To discover those needs, he recommends ‘dogfooding’ what the customer is experiencing and streamlining the onboarding process to be as self-service as possible. He also recommends having measurable insights on metrics you can directly impact, like decreasing time from discovery to ‘hello world.’

    Final Thoughts

    Developer experience is becoming a unique selling point for technology companies—so much so that it’s entered the C-suite. “Whoever has the better DX will have the leading edge,” said Cauduro. For him, it’s about finding small things to optimize that remove pain points from the developer’s process.

    To summarize, the role of CDXO is still evolving and not set in stone. And, granted, many different labels are being applied to describe similar objectives. But to get an idea of what the CDXO role entails, some common activities include:

    • Considering the perspective of the developer.
    • Engaging the entire company to prioritize DX.
    • Overseeing the construction of DX-related assets and resources such as tutorials, documentation and guides.
    • Collecting feedback and reiterating platforms.
    • Overseeing developer relations and advocacy teams.

    Looking to the future, developer experience will likely become more of a necessity as developer-driven purchasing habits become a real revenue driver. “This bottom-up go-to-market motion will help awareness and increase sales,” said Burazin. And, to helm this movement, more companies may adopt DX within a C-suite title. But of course, the role may look different from company to company as DX is applied in different ways.

    “If we look at the largest technology companies, almost all of them have a developer experience department in their organization. And this is due to the fact that so much of a developer’s productivity is directly linked to their experience while working,” said Burazin. Things like internal developer portals and standard cloud deployments will help improve developer experience and help them focus on what they do best, which is coding, he said.

  • OpsVerse Adds Backstage Catalogue to Managed DevOps Service

    OpsVerse Adds Backstage Catalogue to Managed DevOps Service

    OpsVerse this week added an open source Backstage catalogue software for building developer portals to its managed DevOps service.

    Originally developed by Spotify, Backstage makes it possible to centralize the management of multiple services that are being built and maintained by multiple developer teams. Backstage is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

    OpsVerse CEO Arul Francis said the company is now employing Backstage to create a centralized control plane dubbed OpsVerse ONE through which organizations can more easily centralize the management of a DevOps toolchain. Every applications team can see all the services and related resources they own and then via a single click launch a project, he noted.

    The managed OpsVerse platform is based on curated editions of open source software such as Argo continuous delivery (CD) and Prometheus monitoring software that OpsVerse enables organizations to access as a set of software-as-a-service (SaaS) applications. Those applications can then either be deployed in cloud platforms made available by Amazon Web Services (AWS), Microsoft or Google or in an on-premises IT environment.

    The addition of OpsVerse ONE will also make it simpler to extend the OpsVerse toolchain via more than 80 plugins that are currently available for Backstage catalogue software, noted Francis.

    It’s not clear what degree organizations are embracing managed DevOps platforms but at the very least smaller organizations should find it simpler to embrace best DevOps practices by relying on a managed service. There are also plenty of larger organizations that may determine that continuing to manage DevOps toolchains has become problematic after years of integrating various tools and platforms in ways that now are both challenging to maintain and secure. OpsVerse claims to have in the last six months already tripled the number of customers it supports.

    As application development becomes more complex to manage in the age of microservices, many organizations are at a crossroads. They need to decide to what degree it makes sense to continue to devote resources to managing DevOps platforms versus consuming them as a cloud service. Many of the resources that are now allocated to managing DevOps platforms could theoretically be shifted toward building and deploying more applications. In some cases, organizations may decide to continue to rely on legacy DevOps platforms to maintain existing applications while employing a cloud service to build modern cloud-native applications that have many more dependencies than monolithic applications.

    Regardless of the degree to which organizations decide to rely on managed services, platforms such as Backstage as it continues to evolve will make it simpler to extend open source toolchains. Spotify developed Backstage to bring some order to its own internal application development and deployment processes before deciding to contribute Backstage to the open source community. While Backstage is still an incubation-level project within the CNCF, it’s already being used across multiple DevOps production environments to make it easier to integrate additional tools without having to sacrifice their ability to centrally manage a DevOps environment.

  • Automation has Become an Absolute IT Necessity – Techstrong TV

    Automation has Become an Absolute IT Necessity – Techstrong TV

    Vijoy Pandey, vice president of emerging technologies and Incubation for Cisco, explains why automation has become an absolute IT necessity. The video is below followed by a transcript of the conversation.

    Michael Vizard: Hey, guys, thanks for the throw. We’re here with Vijoy Pandey, who’s vice president of emerging technology and incubation for Cisco. We’re gonna be talking about all things related to automation. Vijoy, welcome to the show.

    Vijoy Pandey: Thank you, Mike, pleasure to be here.

    Michael Vizard: Right now, everybody is struggling, looking to find people, hire people, retain people, and this was an issue before COVID came, but it seems like it’s much worse these days, and there seems to be no end in sight. So, what is your best advice to folks about how to think about managing talent these days?

    Vijoy Pandey: Yeah, I think that’s a pretty important point you raise there, Mike. Just like everybody else, we’ve been seeing not just news articles around the great resignation, but also we’re feeling that inside of Cisco as well. We know that our partners, our customers, all of us are feeling that pinch, where it’s incredibly important to retain top talent, but it’s also very hard to find talent, given the trends that we’re seeing around us.

    Anything about cloud computing, anything about AI, all of those things. So, we think of the problem in a very different way. We think – and we’ve done a bunch of surveys inside of Cisco – what we realized was given the global nature of events – we know some events unfolding right now – and all of the geopolitical events happening, all the pandemic, people really are realizing that life is too short.

    It’s not a pithy statement here, it’s actually people believe that life is just too short, and they actually want to do meaningful work. They want to make an impact, not just to the team that they are with, nor the company that they’re with, but even a global impact with the work that they do.

    But they also want to grow and learn, and make sure that they are on a path themselves towards meaningfully improving their own lives. So, I think those are pretty important characteristics that we have gathered, and as organizations and as teams we need to harness that desire to make both local impact as well as global impact as well as figure out how to drive meaning into everybody’s personal lives – yours, mine, our teams’, and so on and so forth.

    So, there’s a bunch of things that we are doing inside of Cisco to make sure that this meaning, or meaningful impact, is nurtured. One of the things that we keep on saying is that yes, there is a business to run, but there’s also an avenue we need to give our employees and our teams to innovate, to look at impact beyond the run-of-the-mill business that any corporation needs to do.

    So, typically what we end up doing is we end up taking problem statements that we face, let’s say, as a team or an organization, and we start splitting it into buckets. So, think about buckets that deal with run-of-the-mill business, because that, you need to absolutely take care of.

    But also, there are buckets that you need to innovate around or do meaningful work around. So, we have a portfolio management system inside, at least on my team, that says let’s take 60 percent of your time and make sure that that’s allocated towards run-of-the-mill business as usual projects, and then maybe 30 percent of the time which is future-looking and adding new features or looking at new markets and so on and so forth, and maybe 10 percent of your time is actually towards growing yourself, nurturing yourself, or making some meaningful impact on the global stage. So, that’s actually how we’ve been viewing the problem.

    Michael Vizard: Early on, I think a lot of people were intimidated by automation, and there was concerns that people might lose their jobs. Now, I wonder if we’ve flipped that entirely, where people are saying hey, I don’t really wanna work for organizations that don’t have automated IT process in place because of your points – there’s just things that I don’t wanna spend my day doing anymore. So, has the whole conversation flipped, as far as automation is concerned?

    Vijoy Pandey: I would say the conversation is flipping as we speak, again, yeah, going back to the previous comment, yes, people don’t want to spend time on repeatable tasks, on things which a computer can do better than you and I can do. I have this constant struggle with my kid nowadays as to why do I need to learn grammar when there’s Grammarly? But that’s a different matter.

    But I think it’s a similar mindset going through every individual in the workforce, as to am I really adding value in the workplace, and am I being more productive, which in turn translates is the organization being more productive, which in turn translates to is the economy and the country being more productive.

    So, I think the bump towards productivity is definitely a goal that people are more concerned about, and you hear the other side of this, which is, as you pointed out, is the digitization of the workplace is the digitization of all economy. That’s in progress.

    We’ve called that using various phrases – software eating of the world, or the API economy – whatever term that you want to use. But we are moving towards a world where software is critical in driving everything that we do. Software in terms of automation, or even beyond that, is definitely key to whatever we do.

    Michael Vizard: Not too long ago we all thought we’d be running around by flying cars by now, and that IT would be easy. We’ve seen neither, and it looks like IT is getting more complex than ever. So, my question to you is is IT getting to the point where it is just too complex to manually deal with and we need automation, because we are seeing all these microservices, serverless frameworks.

    There’s all our existing monolithic applications, it’s distributed all the way out to the edge now. Have we reached some sort of inflection point?

    Vijoy Pandey: Yeah, I think to your point IT is definitely way more complex than it was even a decade ago, and I think the crux of the matter is that the way you are building applications and all of the digitization that we talked about is actually taking place in a very, very distributed manner.

    So, as an application developer, first and foremost, we at Cisco like to say that the application is your brand. So, if I am a bank, how my customers interact with the apps that I build defines me, my company, my bank, as the brand. Because if bank A has more capabilities in their software, their mobile app, versus bank B, I will migrate towards bank A.

    So, I think the application is becoming the front end to everything customer experience is all about. So, if you take that notion and play it out, that means the application developer that is developing those applications is under extreme pressure to deliver velocity behind features, do deliver trust with the data of the customers, to deliver uptime and security and so on and so forth.

    So, which means that they are picking and choosing all of these APIs that exist anywhere to make their job faster, easier more secure, more trustworthy. So, if you think about that kind of an environment, as a developer, I’m picking APIs from cloud providers, SaaS providers, I have legacy systems, I have transaction systems, I have edge devices, in the case of a bank. It might be sitting at a branch office.

    I have all of these APIs and systems that I need to interface with just to build one particular app or feature. So, in this kind of a distributed environment, think about the IT – more IT people, right? It’s like I’m trying to build a platform that caters to these kind of demands, and so it is definitely getting more complex, it’s getting more distributed, and every provider in the distributed environment has their own semantics, their own lifecycle management behind their APIs and their infrastructures.

    So, automation – I mean, it’s just humanly impossible to not just deploy but even manage and observe such a highly distributed – and secure, by the way – such a highly distributed system. So, automation is key to doing all of this, a direction automation, to me, is discoverability.

    It’s intent-based, it’s security, which is there’s no longer a perimeter of security, and it’s observability across all of these end points, API to mainframe. That is key to moving forward.

    Michael Vizard: Do you think as we go along that organizations – at least some of them I talked to, it’s almost like a chicken and an egg kind of issue. They have so much legacy stuff that can’t be automated that they can’t invest in automation, and they can’t necessarily buy all new platforms tomorrow. So, how do we get over the automation hump to kind of get from point A to point B without necessarily breaking the IT budget?

    Vijoy Pandey: Yeah, that’s a great point. I think some of that, I’ve dealt with in my previous lives as well. The way to do that is – and there’s no questions about it, that for some period of time, there is going to be more chaos and more money spent than before that time or after that time.

    So, we just have to acknowledge that as vendors, as customers, as organizations, that for some period of time, there’s going to be turmoil. That’s the way, at least, I’ve handled it in the past, where you say let’s put milestones, where we say maybe we look after a pocket of the organization, and say we’re going to build this out in a highly automated, distributed, cloud-first, API-first manner.

    This part of the application, this part of the infrastructure goes out and does that. To do that, we’re going to do a clean slate process here. So, we’ll think about – we won’t get ourselves bound to organizational boundaries, skill set boundaries – that is very hard to do. Most people’s jobs, peoples’ skill sets, organizational structures, all of that.

    But we have to try in some pockets, and then give ourselves strict guidelines and metrics, and try and meet those metrics. If we meet those metrics, the resulting outcome is that I will be spending less moving forward than I’m spending today.

    So, I might spend a little bit more in getting maybe SREs or software engineers, and marrying them up with IT folks or architects, and getting something going. I’ll give myself a timeline of let’s say a year or 18 months; it cannot be longer than that, otherwise it’s a science project. 

    But after those 18 months, these are the metrics I’m going to come back to. I’ll get X percent improvement in productivity, and Y percent reduction in head count, let’s say. We shall measure ourselves to that objective, and I’ve seen that work.

    If it works – and start with something simpler. But go all the way, don’t go 80 percent. Let’s not do 80 percent automation or 80 percent of the use cases. Hundred percent automation, 100 percent of the use cases for this pocket of your environment, and then grow that out over time.

    Michael Vizard: We, of course, hear a lot about artificial intelligent and AI Ops. Are the machines gonna save us from ourselves? What’s the reality of AI?

    Vijoy Pandey: To me, AI is a tool, just like all of the other tools that we’ve talked about, which is we’ve talked about automation or infrastructure as code, we’ve talked about cloud native and serverless and microservices. Each one of these tools, programming and scriptings tools.

    So, all of these tools bring in something to the table, and infrastructure as code brings in consistency and intent-based infrastructures, and serverless and microservices, or cloud-native, bring in immutable architectures.

    The fact that you can grow and scale out and do all of those things, and availability goes through the roof and velocity goes through the roof. Similarly, AI and ML bring in insights to the table where it was humanly, again, impossible to do that just by looking at the vast variety of data and the deluge of data coming our way.

    If we could just take all of that – and it’s all unstructured. So, if I could take all of that and somehow put it in a structured database and somehow make sense of it as an individual, sure, we don’t need the AI or ML. But if I need to take all of that unstructured data and make some sense out of it, there’s no other way out, and I do need AI and ML.

    I mean, I do need some statistical mechanism first, to figure out and make some sense out of it. I do need AI/ML, maybe deep-learning, to make some sense out of it. But then I need to marry that tool with subject matter expertise, I need to marry that tool with what I as an individual, or as humans, we’ve learned in the past, because AI doesn’t have that context.

    Yes, we can do learning, all sorts of learning, but it doesn’t always work in all kinds of environments. We need to marry that with subject matter expertise, with some boundary conditions, and then we need to marry it with actions. Because AI/ML is gonna give us insights, but somebody needs to take actions on the insights.

    So to me, it’s a tool in the toolbox, and we need to leverage it when it makes sense. We need to rely on subject matter expertise when it makes sense, and eventually things will get to a point where we need to go to the next level of abstraction. 

    So, it’s always a game of moving that level of abstraction higher and higher, and that’s what we are after. So, maybe someday there will be flying cars and robots that will take all our jobs, but not right now.

    Michael Vizard: How do I bridge this divide in IT that maybe we don’t talk enough about, but there’s clearly a DevOps community that’s very programming-centric. The use APIs. Then there’s traditional IT administrators that use ITSM tools. They tend to be more graphical in nature. As we move forward with automation, do you think that those two camps are gonna converge, or how will this all play out?

    Vijoy Pandey: In my opinion, I think they have to converge. I think each one of those pieces have their space in the hierarchy of things. One of the things I learned pretty early on in one of my previous lives is what good is a dashboard if you cannot take an action on it?

    So, if you think about all dashboards that exist today, eventually, there is data being presented in a certain way about a certain problem, so that somebody can look at that and take an action. If you think about infrastructure as code, it’s exactly that.

    It’s basically let’s remove the dashboard, and let’s figure out what goes – triggers that, that allow me to take those preset actions. Let’s try and remove the action of a human looking at a dashboard, thinking about it, and taking some action on it.

    Now, again, I’m describing utopia, but I think that’s where, as engineers, as operations folks, we all need to move towards. To me, dashboards are a good start when the problem is less well understood. As we understand the problems better, we need to move towards code.

    Dashboards will still have their place in helping us understand more and more complex problems, but as problems are better understood, they need to move towards code. And that’s the way at least I think through it.

    Michael Vizard: All right, so automation needs to be our new North Star, as it were. Hey, Vijoy, thanks for being on the show.

    Vijoy Pandey: Thank you so much, it was a pleasure, and I enjoyed our conversation.

    Michael Vizard: All right, back to you guys in the studio.

  • Postman Survey: Increased Usage of APIs Results in More Security Incidents

    Postman Survey: Increased Usage of APIs Results in More Security Incidents

    A survey of more than 37,000 developers and application programming interface (API) professionals published this week by Postman, a provider of a platform for developing and managing APIs, suggests that as more APIs are deployed, more organizations are seeing a rise in cybersecurity incidents.

    The survey finds more than half of respondents (51%) reporting that more than half of their organizations’ development effort is spent on APIs. About 20% also noted they are responding to API security incidents or breaches at least once a month at their organization. Overall, more than half (52%) said API security incidents occur less than once a year.

    Kin Lane, chief evangelist for Postman, said that while a lot of the concerns over API security could be classified as “theater” being put forth by providers of API security platforms, it’s clear there is a need for a zero-trust approach to building, deploying and maintaining APIs.

    The bulk of APIs are used primarily to interconnect internal-facing applications and systems, with a subset then used to integrate partners. Only a comparatively small percentage of APIs are externally facing. However, Lane noted many organizations fail to appreciate how quickly an internally facing API can become externally facing over the course of its lifecycle. As such, IT teams need the tools and platforms required to manage and secure APIs as they evolve, he noted.

    In fact, nearly three quarters of respondents (72%) said being able to build APIs remotely is very important to them. That would suggest best DevSecOp practices will need to be extended to API development teams that are often working from home.

    Despite those concerns, however, a full 89% said Investments in APIs will increase or stay the same over the next 12 months to drive, for example, digital business transformation initiatives. However, the survey also suggests most organizations are still coming to terms with API development and deployment. Only 8% of respondents identified themselves as API-first leaders, which Postman identifies as an elite group that produces APIs faster, deploys more often, has fewer failures and recovers sooner when failures occur.

    Lane said the survey makes it clear that while APIs are playing a crucial role in advancing business goals, there is a need for increased visibility as more APIs are deployed across the enterprise. That’s especially critical as more types of APIs employed also continue to expand. Most APIs in use today are based on the REST format, but there are also now APIs based on GraphQL, event-driven architecture and various messaging platforms. None of these newer APIs are going to supplant REST APIs any time soon. Rather, they are being applied to drive additional processes alongside REST APIs, noted Lane.

    It’s not clear how many organizations are adopting a design-first approach to building APIs before they write application code, but as more APIs are deployed, the way IT is managed is rapidly changing. Application services are essentially becoming more disposable so long as the API used to expose them to other applications remains stable. In fact, it’s now only a matter of time before most organizations fully appreciate the degree to which their entire IT strategy now revolves around their APIs.

  • Civo Report Surfaces Growing Cloud Lock-in Concerns

    Civo Report Surfaces Growing Cloud Lock-in Concerns

    A survey of 100 IT professionals conducted by Civo, a provider of cloud services based on Kubernetes, finds a total of 82% currently rely on either Amazon Web Services (AWS) or Microsoft for public cloud infrastructure. However, more than a third (34%) of respondents also report they now feel locked into the public cloud service provider.

    The primary reason survey respondents cited for feeling that way is data transfer costs are too expensive to move off their current cloud (65%).

    Simply inertia also seems to be a factor. A third of the total respondents (33%) said they had always used the same cloud service provider. Nearly two-thirds (62%) also noted they were concerned that alternative cloud providers would suffer more outages. At the same time, however, 45% of respondents conceded they are under growing pressure to reduce cloud costs.

    Civo CEO Mark Boost said it’s already apparent that cloud outages are not just limited to alternative cloud providers. In fact, most application workloads are relatively simple in the sense they can run equally well with the same level of resiliency on any number of cloud services at a lower cost than the major hyperscalers currently charge, he noted.

    In effect, cloud computing, except for some more complex workloads, should largely be viewed as a commodity, added Boost.

    Cloud service providers, of course, discourage migrations using exorbitant data egress charges that often make moving data off their platforms cost prohibitive. In fact, most applications are deployed on a single cloud versus in a truly hybrid cloud model because data management can become exceedingly complex. Ideally, IT organizations would like to be able to play one cloud service provider off another to reduce costs. In practice, however, once an application is deployed, it rarely moves to another platform.

    On the plus side, however, microservices-based applications deployed on Kubernetes clusters are easier to move because each instance of a Kubernetes cluster exposes a consistent set of APIs. However, stateful applications deployed in Kubernetes environments can like any other application become dependent on, for example, a proprietary database.

    The tradeoff, of course, is that each cloud platform added to an enterprise IT environment tends to increase total costs. IT staffs typically need to hire additional specialists that require tools to manage each cloud. There are, naturally, platforms that span multiple clouds but the cost of acquiring, provisioning and maintaining those platforms can be considerable. In the meantime, more organizations find themselves separately managing and attempting to secure multiple clouds simply because individual departments prefer one cloud service versus another.

    It’s not clear to what degree organizations may soon decide to consolidate cloud workloads as part of an effort to reduce costs. However, a lot of workloads in the immediate aftermath of the COVID-19 pandemic were shifted to the cloud with little regard for cost. Now that organizations are adjusting to the so-called new normal, many of those decisions are, at the very least, being re-evaluated to see what might make the most financial sense as the general economy seems to become less predictable with each passing day.

  • Tackling the Complexities of Multi-Cloud With a New IT Model

    Tackling the Complexities of Multi-Cloud With a New IT Model

    The pandemic put incredible pressure on organizations to modernize and accelerate digital transformation efforts, with many businesses rushing to embrace cloud strategies in response. According to this year’s Enterprise Cloud Index from Nutanix, multi-cloud—an IT operating model that combines multiple clouds, public or private—is the most commonly deployed IT environment and the only IT model on an upward adoption trajectory. In fact, nearly two-thirds (64%) of organizations plan to operate a multi-cloud environment within three years.

    But there are complexities and challenges of managing across cloud borders that organizations are still grappling with, and concerns about security, data integration and cost remain. Enterprises will need to find ways to leverage existing cloud investments and redefine best practices and what it means to have agility and resilience in IT.

    Current Challenges

    Businesses have traditionally been designed around managing costs, increasing efficiency and streamlining operations, but lean IT teams find themselves under new pressures to support the challenges we’re facing today. The pandemic forced organizations to prioritize implementations and view the public cloud as a quick solution for everything without proper due diligence at the expense of optimization. This approach lacked focus on strategic business outcomes, and ultimately led to increased complexity, higher costs and less flexibility. According to the study, 87% of respondents agreed that multi-cloud success requires simpler management across mixed-cloud infrastructures.

    Enterprises also continue to rank improving security as a top IT priority, yet managing security was among the top multi-cloud challenges cited. Additionally, the majority of respondents (80%) say that moving apps can be time-consuming and costly, and 77% agree that workload portability is a significant challenge. This underscores the need for uniform management and operations across different cloud environments to avoid costly and time-consuming efforts to move applications.

    “Cloud-Smart” approach to IT

    Current cloud thinking is that there’s a “best” cloud environment for each workload or application, but there is no one-size-fits-all approach to the cloud. Organizations will start to move away from blanket cloud-first approaches to IT, and instead, be more thoughtful about which workloads run where. It is no longer a foregone conclusion that taking every app or workflow to the cloud permanently is the best course of action. The adoption of this “cloud-smart” approach, leveraging the most appropriate cloud environment for each use case, is likely a primary driver behind the proliferation of multi-cloud.

    The use of IT infrastructure by organizations is becoming more strategic over time. Nearly three-quarters of IT professionals (72%) feel that the IT function in their businesses is seen as more strategic now than it was a year ago. While businesses are now viewing and using IT more strategically than ever before, the complexity of multi-cloud is creating challenges that are standing in the way of cloud success. Despite challenges, a strong case is made for why the future of IT is hybrid multi-cloud, a model that enables more operational consistency across clouds. In fact, 83% consider it ideal.

    Multi-Cloud Supports New Ways of Working

    The pandemic has changed how nearly all organizations operate, and the top reasons cited by businesses for changing their infrastructure and deployment models are improving remote work and collaboration. While an organizations’ remote workforces may fluctuate, they are here to stay for the foreseeable future and IT will need to be nimble to support a remote, hybrid workforce and keep people productive and connected regardless of location.

    Over half (61%) of organizations are focused on offering more flexible work setups because of the pandemic, and multi-cloud supports this new way of working. It offers the most agile IT environment for supporting this kind of flexibility by distributing data and allowing remote access to business applications from diverse geolocations for user proximity and business continuity, and enabling organizations to implement technology that helps retain and attract talent.

    Multi-cloud is here to stay—and is the only operating model that is expected to increase in the coming years. 2022 will bring about a shift towards hybrid multi-cloud deployment as organizations look to take advantage of what each cloud has to offer while still having the flexibility and freedom of choice around their applications and data. This would deliver on the flexibility and agility that most organizations seek to compete in today’s digital world while enabling enterprises to significantly simplify operations. Future-proofing cloud strategies is the key to building IT resilience.