Category: Blogs

  • DevOps: Driving Innovation With Old Habits

    DevOps: Driving Innovation With Old Habits

    DevOps can help drive cost-efficiency, greater productivity and innovation

    When software development and IT operations merge and work in a state of harmony, they create a flow that we call continuous product delivery. Ideal for project managers, this flow is the elixir to innovation and enables the agility needed to respond to changing market requirements. It also creates currents of speed, proactiveness and integration within enterprises. However, asynchronous code updates, inadequate IT infrastructure, siloed functioning and inefficient processes can hinder this flow.

    In 2009, Patrick Debois and Andrew Clay Shafer devised a framework to break such barriers and coined it “DevOps.” Over the last decade, DevOps has garnered many followers and fans, including myself. Product managers worldwide rely on DevOps to enhance performance, accelerate time to market and innovate with agility. DevOps is more critical today than ever before—when nature mandates a new order of remote working, product managers must rely on DevOps to catalyze innovation and sustain continuous product deployments and updates.

    Yet, not all enterprises that have adopted DevOps have unearthed innovation like that of Dyson, which created a new type of ventilator in a mere 10 days to help the UK government scale COVID-19 treatments. Nor have they been able to match the frontrunners of innovation such as Google and Amazon that can deploy code thousands of times per day, compared to low performers that deploy code only about four times per day. The obvious question on everyone’s mind is, “What are these heroic innovators doing differently with DevOps?”

    Driving Success Through DevOps

    While business executives are aware that implementing DevOps drives business innovation, most are not aware of the old habits that remain, causing unnecessary hiccups within the application cycle and business transformation. As the way forward, organizations must tweak their approach to DevOps to be able to reap more significant benefits of business innovation. They must:

    Ensure speed does not outpace stability

    Today’s digital-first world has swept through every enterprise. However, to keep up with the rapid dynamics of the digital tide, enterprises need to weed out monolithic architectures and manual processes to turbocharge software development and deployment. Automating the deployment process with the help of microservices and cloud can help enterprises gain speed in software deployments and swim the tide of customer experiences. Speaking from experience, this is a privilege that has allowed me to witness how DevOps practices have enabled enterprises to crunch deployment times from weeks and days to just a few minutes. Needless to say, innovation depends on speed: The faster an enterprise deploys a novel solution, the higher its chance to claim the prize of innovation.

    A word of caution here: Many enterprises that have neglected quality and stability while accelerating speed drown in a vortex of defects often. When pushing out a product or an application 30 times faster than the traditional model, enterprises must consider its stability, too. Cloud infrastructure plays a vital role in helping enterprises achieve both stability and speed. On-demand self-service, networks that cater to multiple devices, high scalability and analytics are some of the primary advantages that enable enterprises to deploy faster without impacting the core.

    Losing stability for the sake of speed can cause organizations to regress instead of leaping forward. In recent times, British Airways has been in the news for repeated issues in its IT infrastructure’s stability. It has had to cancel several flights and inconvenience passengers because software upgrades and incidents have caused its infrastructure to fail. Enterprises must consider these four metrics—lead time for changes, deployment frequency, time to restore service and change failure rate—to receive the value of their DevOps investment.

    Make security equal to agility

    The pandemic-driven remote working has seen the video communication solutions provider Zoom soar to 300 million active monthly users last month. The brand showed great agility in meeting the surge in demand but became vulnerable to cyberattacks—500,000 Zoom passwords were available for sale in the dark web’s crime forums last month. This is an excellent example of how security is usually an afterthought when compared to agility; not prioritizing security in the DevOps cycle can place teams and their organizations at significant risk, creating vulnerabilities and exposing organizations to bad actors.

    In my experience, putting security checks in place early in the DevOps process can help enterprises shift left more effectively. As a first step, security and development teams need to communicate better through the continuous delivery flow. Security teams need to play more proactive roles in foreseeing risks in innovative solutions and routine software updates. Leaving security for the last will only force organizations to be reactive versus proactive.

    Build collaboration, not silos

    Gartner predicts that through 2022, 75% of DevOps initiatives will fail to meet expectations due to issues around organizational learning and change. DevOps is a process that provides tools but it is also a philosophy that promotes collaboration among teams in software development. It catalyzes an ecosystem that encourages high collaboration and information-sharing. In a DevOps culture, failure is not shot down but leads to inquiry that drives solutions. Seamless information flow is the critical outcome of a DevOps-driven organization. Proper information flow is timely, answers questions and is understandable while needing the support of tools and technologies to drive success.

    The General Motors Freemont Assembly line has been a great case study of how poor workforce culture can cause an enterprise to shut down. As one of the largest automobile factories in the United States, the manufacturer had to shut shop in 1982 due to rising losses attributed to an unruly workforce that was protected by a strong union. Within the next two years, the same factory was re-opened in collaboration with Toyota Motors, and it was called NUMMI.

    NUMMI hired up to 85% of the old workforce of GM’s Freemont assembly. The difference was the Toyota culture–one that focused on learning and improvement and set a framework of how leadership interacted with and inspired teams. This change was fundamental in driving success for NUMMI, which reduced the time to manufacture a car to 20.8 hours in 1986—a drastic improvement over 43.1 hours in 1978.

    At a time when we are witnessing unprecedented disruptions to supply chains, manufacturing and employment, enterprises need to deep dive into functioning to explore new opportunities for cost-efficiency, greater productivity and innovation. DevOps can help achieve these and build the foundations for continuous innovation. Investments in automation, cloud and culture will help enterprises realize the continuous flow of product delivery and innovation. The wave of innovation in the new normal will be propelled by the forces of time-tested practices and new next-generation approaches to enable enterprises to shift-left.

  • Low-Code: An Oasis During Developer Drought

    Low-Code: An Oasis During Developer Drought

    Key insights from Mendix’s 2020 Developer Drought Index

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

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

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

    ‘Developer Demand Index’ Study

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

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

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

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

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

    Conditions for a Drought

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

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

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

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

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

    COVID–19 and Remote Work

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

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

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

    Low-Code Waters Fill a Developer Drought

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

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

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

    Final Thoughts

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

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

  • Z is for Zowe – the Open Path to Mainframe DevOps

    Z is for Zowe – the Open Path to Mainframe DevOps

    The energy and excitement in the IBM Z mainframe community during the two years since the announcement of Zowe have not been seen in a generation.  By enabling mainframers to work like technologists who work on the cloud, mobile and distributed platforms, Zowe unlocks the power of DevOps for mainframers, ensuring the vitality of the platform for the long-term.

    It accomplishes this by opening up the world of enterprise DevOps tools, both familiar and special-purpose ones, for mainframe applications, allowing users to easily create toolchains that include the mainframe. This freedom to leverage any enterprise DevOps tools across the entire deployment pipeline is achieved simply and elegantly.

    The Zowe Backstory

    The Zowe journey began when Broadcom, at the time CA Technologies, along with IBM and Rocket Software realized the challenges they were hearing from customers—IT isolation, need for increased delivery velocity and recruitment and retention problems—were bigger than any single vendor could solve on its own. The challenges of this scale required an ecosystem-wide response.

    So the vendors came together with the Linux Foundation’s Open Mainframe Project to create the open source framework known as Zowe (as in David Bowie, for the uninitiated). The Zowe community operates transparently and welcomes contributions from all in the form of code, enhancement requests, educational content and shared experiences. A virtual meetup held earlier in the year attracted participants from 47 companies from across the mainframe ecosystem.

    Traditionally, mainframe application development and operations have been separate from the rest of the IT organization due to specialized processes, roles and tools designed around the platform. While they have served the mainframe community extraordinarily well over the decades, the world outside has changed with demand for ever-shorter software delivery cycles resulting in the DevOps model.

    In short, the tipping point has arrived and the time to normalize is now.

    What Is Zowe?

    Zowe is a modern interface to the mainframe that extends z/OS-based services and tooling to the greater IT landscape, including DevOps. As a framework, it consists of four main components:

    • Zowe API Mediation Layer (APIML)
    • Zowe Command Line Interface (CLI)
    • Zowe Explorer (Visual Studio Code extension)
    • Zowe App Framework (UI)

    Broadcom is proud to have initially contributed the first three of these components. The first two were created as part of our CA Brightside offering, which won an award for the Most Innovative DevOps solution—yes, a mainframe offering won a DevOps innovation award!

    These components provide a modern way of working that supports core DevOps practices such as empowering developers with shift-left testing responsibilities and DevOps engineers with robust automation options.

    This article describes the framework’s ability to onboard the mainframe to enterprise DevOps, so developers, systems programmers and others who work with the mainframe can now do so the same way their peers do with other IT platforms (i.e., cloud, mobile, distributed). These shared experiences close the gap between mainframers and others while preserving the core advantages of the platform. Common tools fuel a common language that benefits all, especially when deploying hybrid applications (e.g., web front-end with mainframe back-end).

    Through automation and script libraries, Zowe helps reduce the range of mainframe-specific knowledge necessary to be productive, enabling organizations to more easily recruit, onboard and retain the next generation of talent. By using modern DevOps tools and techniques combined with access to “big iron” applications, the next-generation now sees mainframe as an exciting career choice.

    Recent milestones achieved by the Zowe community include the launch of the long-term support (LTS) release ensuring the stability and longevity of the framework and a Zowe Conformance program ensuring the interoperability of a growing ecosystem of conformant tools.

    The framework drives mainframe DevOps in several ways:

    Zowe API Mediation Layer – Discover and Securely Consume

    As RESTful APIs become table stakes, the greater the challenge becomes, making those services easily discoverable and consumable in a secure way. The Zowe API Mediation Layer (APIML) addresses this need by exposing mainframe services, ranging from z/OS system level to database/transaction services to tool-based services, through a centralized gateway and catalog.

    Conformance of these APIs with the Zowe LTS standard eliminates breaking changes while bringing additional value, including the usability and productivity benefits of single sign-on (SSO).

    At Broadcom, we’ve leveraged Zowe to achieve conformance across our product portfolio and have a healthy pipeline of Zowe-conformant products soon to be announced. By spanning the traditional Dev and Ops domains, we’re facilitating true mainframe DevOps adoption—teams can combine their preferred mainframe-native tools with off-platform ones, including ones used by their peers working on other platforms, to optimize speed, quality and productivity.

    Zowe CLI – Orchestrate and Automate

    For DevOps Engineers and DevOps-savvy self-service developers, CLIs are a “go-to” tool. They use CLIs for a wide range of platforms including AWS and Azure, Git, Kubernetes and so on … why not mainframe? The use of CLIs paves the way for robust, script-based automation, which is a cornerstone of DevOps. The Zowe community already offers some basic scripts, free for anyone to use.

    Using a CLI may be new for some, so community members often share tips and tricks to help these users navigate the productivity curve quickly.

    Broadcom currently offers a dozen or so CLI extensions to mainframe-native tools, once again spanning the traditional Dev and Ops domains to improve productivity across roles and processes.

    Zowe Explorer for VS Code – Visualize and Navigate

    Visual Studio Code is exciting for any mainframers editing code, especially developers and sysprogs. While ISPF and Eclipse will remain viable options for the foreseeable future, the extraordinary success of the lightweight VS Code, which is backed by Microsoft, and the rapid emergence of browser-based editors/IDEs expand the range of options. With 11 million users around the globe, VS Code provides an experience users love and a marketplace of 20,000 extensions enabling users to personalize their UX and optimize their workflows.

    Zowe Explorer, which streamlines interaction with mainframe data sets, USS files and jobs, is only one of the many VS Code extensions available in the VS Code marketplace for mainframe users (and a successful one with more than 12,000 downloads). Unlike Eclipse extensions, all of the mainframe extensions from Broadcom are free, and many are open-sourced.

    In the Queue: SSO/MFA, SDK, Mobile App

    The Zowe community has been working diligently on the implementation of SSO and multi-factor authentication (MFA), which eliminates the drudgery of constantly logging on to multiple systems.

    Also, software development kits (SDKs) are in the works, the goal of which is to make Zowe services (and by extension, the mainframe) easier to use by providing reusable code for common mainframe operations in popular languages and runtime libraries. The beginnings of a Zowe Node.js SDK and Zowe Python SDK already exist.

    Finally, a Zowe mobile app to help systems and operations support staff improve system availability is, like the SDK, being incubated by the community.

    Decision Time – Zowe Open Path or Closed, Proprietary

    Mainframe teams face a choice: Continue with a vendor-controlled model, in which vendors determine which tools you use and how you work or adopt the open path. While the prescriptive (aka opinionated) approach of the former may have been acceptable for a siloed mainframe, the open approach is the foundation of enterprise DevOps.

    As an indication of the early success of the open path, we’ve been delighted to learn about many mainframe shops adopting Zowe on their own, with CI/CD integration and code analysis a common entry point.

    For those with reservations about open source, consider the prevalence of Git, Visual Studio Code, Jenkins, SonarQube and so on in the DevOps landscape. Microsoft CEO Nadella recently stated, “We’re all-in on open source” and Zowe co-founder IBM recently acquired Red Hat—more shining examples that open source tools are a trusted part of the technology stack.

    Change is never easy, which is why no-fee Design Thinking workshops are available to help adopters prioritize the DevOps use cases enabled by Zowe. Because so many see “open” as the least costly, least risky and fastest path to mainframe modernization, familiarity with Zowe is quickly becoming an industry standard. Ask your vendors if they’re joining the Zowe community and ecosystem.

    With ongoing commitment from IBM, Rocket and Broadcom and the guidance and support of the Open Mainframe Project, the excitement around will Zowe continue so join the open mainframe movement!

    To learn more about Zowe, visit Zowe.org and the community blog site.

  • CircleCI Looks to Advance DevOps Best Practices Adoption

    CircleCI Looks to Advance DevOps Best Practices Adoption

    CircleCI today launched a developer hub as part of an effort to further advance adoption of DevOps best practices.

    Company CEO Jim Rose said CircleCI developer hub provides access to a set of resources for optimizing continuous integration/continuous delivery (CI/CD) pipelines. In many cases prior to the onslaught of the COVID-19 pandemic, organizations had only partially implemented best DevOps practices, noted Rose. The CircleCI developer hub will make it easier for those DevOps teams to extend the scope of those processes while serving to educate IT teams that have had limited exposure to DevOps workflows, he said.

    The CircleCI developer hub provides access to, among other things, CI/CD configuration optimizations and pre-built packages, migration guides and documentation. There are also reusable snippets of CircleCI configuration code, customized open source Docker images that can be used on any platform, and command-line interfaces (CLIs) and application programming interfaces (APIs).

    Later phases of the developer hub will include an orb development kit to help users quickly create new orbs using CircleCI CLI commands. An orb is a software development kit (SDK) that simplifies integrating the CircleCI CI/CD platform with third-party tools and platforms. CircleCI also plans to provide a much more streamlined search engine experience for CircleCI documentation.

    The CircleCI developer hub was built in part using $100 million in additional funding the company raised earlier this year. Overall, CircleCI claims it processes nearly 2 million jobs across 100,000 projects per day.

    In general, Rose said DevOps is becoming more challenging as organizations attempt to orchestrate the building and deployment of monolithic and microservices-based applications constructed using container and serverless computing frameworks. There are plenty of instances in which deploying a monolithic application is still more appropriate, so IT organizations need to be able to create DevOps workflows capable of spanning multiple classes of frameworks and platforms, he noted.

    Making matters more complex is the testing of microservices now needs to be integrated within production environments, added Rose. It’s not really possible to completely test a microservices until IT organizations see what impact it might have on other microservices that have already been deployed in a production environment, said Rose.

    It’s not clear what impact COVID-19 has had on the productivity of DevOps teams. It might be easier for developers to generate more code working from home than in the office. However, generating quality code at the right time during a project requires a lot more orchestration when members of the application development team are highly distributed. More than a few organizations either already have or soon will be tuning DevOps workflows to align with the so-called new normal.

    Of course, there are plenty of places to find tips and advice when it comes to building and extending DevOps workflows. The challenge is creating workflows that are not only flexible and resilient but also simple to implement and maintain.

  • What Is Resilience Engineering?

    What Is Resilience Engineering?

    Admitting things will go wrong isn’t easy for anyone or any team. But modern engineering practices have moved beyond this fear, giving birth to a new practice in DevOps and site reliability engineering (SRE) known as resilience engineering.

    Resilience engineering today isn’t thought of as a function. However, just as DevOps was a description of culture before it was a role and site reliability was an extension of operations before it was a focus, I wouldn’t be surprised if resilience engineering became a function in the new future. The first question most will ask however is, “Isn’t this just SRE?” The purpose of the term is to change the focus from simply reacting to incidents to developing long-term response strategies for them.

    Because the expectation in these environments is that things will break, resilience is the responsibility of existing DevOps and cloud operations teams. When applications and services do break, a “fly by the seat of your pants” response strategy will not work.

    A Focus on Frameworks

    Resilience engineering, while rooted in engineering practices, is largely focused on building strategies and a framework for their execution. This leaves the process of building resilience into a largely unestablished system in part because each system is unique. And, how you respond to issues in that system will likely be unique, even if the management plane that reports issues is not.

    The job of resilience engineering is to:

    Establish procedures, habits and decision trees

    When things break, fight is the only option. Operators and on-call engineers need to address issues in a systematic and repeatable way and do their best to remove emotion and fear from the equation. This not only helps triage and resolve issues, but it also makes sure the activity associated with the issue leads to meaningful insights in post mortems and future collaboration. Part of that is establishing habits and decision-making processes for those who are on-call. The processes help prioritize what to focus on, help catch details because details are critical.

    Be data-driven

    Resilience engineering must rely on data. This is another place where traditional SRE practices grow with a focus on resilience. In typical SRE environments, the focus is on the now, using real-time dashboards of the current state. When you think about resilience you are thinking about the past’s impact on the future, not the now. The only way to do that is to make sure the data supports it; thus, part of resilience engineering is making sure the data is there. Instead of data silos that most organizations have across their delivery chain. Resilience engineering should ensure that telemetry across the entire delivery chain is captured, correlated and shared. The reason this is critical is that what happens early in the delivery chain directly impacts incidents. That activity can be the source of answers, it can be the triggers for rollback, or it can be the clarity needed to prevent similar issues in the future. Without continuity between each stage of the delivery chain, it’s easy to miss correlated events that can lead to more systemic problems.

    Engineering out of reproducible incidents

    For most, the best part of resilience engineering is taking what is learned from previous incidents and finding ways to automate future resolution. Learning from data and having consistency in habit leads to the ability to create runbooks and automate remediation for known issues. Often incident response audit trails can read like playbooks for addressing issues of a particular type. When the resolution is not directly related to code and the potential of issues to surface again in the future is inevitable, being able to build intelligence to address it saves waking someone up at midnight and much shorter impact on customers.

    The Resilience Stack

    Organizations looking to embrace resilience engineering need to have a toolkit built for it. It’s pretty straightforward but worth highlighting. The resilience stack will include:

    1. Observability and/or monitoring tool.
    2. Incident response tool.
    3. On-call strategy documentation.
    4. Post mortem process and documentation.
    5. Documented processes including recommend response steps.
    6. Path to automation.

    For those with a relatively mature and automated environment, the next step is chaos engineering—embracing chaos as a way to get ahead of incidents before they happen in the wild.

    Get your markdown skills to maximum level. There is a lot of documenting that needs to happen with comprehensive resilience engineering. But these documents should not be shelf-ware—they should be living and ultimately lead to the implementation of automation or feedback to development.

    As for monitoring, observability and incident response tools, it’s not enough to simply implement them. Knowing how data will be collected, consumed and actualized is also necessary. So is establishing an on-call strategy with purpose, not just because having everyone on-call is the “cool thing to do.”

    It may seem obvious to say that organizations want system resiliency. What is not obvious is how to execute it. When organizations see the gaps (and are often embarrassed by them), they understand that resilience is a focus for either current functions or new ones in the future. That is why it’s worthwhile to talk about resilience engineering and what makes it effective.

  • Survey: Cloud Security, DevOps Emerging as Enterprise Priorities

    Survey: Cloud Security, DevOps Emerging as Enterprise Priorities

    A survey published today by 2nd Watch, a provider of IT services, finds that in the wake of the COVID-19 pandemic, cloud security and DevOps have emerged as the top two priorities for large enterprise IT organizations.

    The survey queried more than 100 IT directors working at companies with at least $500 million in annual sales and IT budgets of at least $50 million per year, Three-quarters of respondents (75%) said they are prioritizing cloud security, followed by cloud-native culture change, also known as DevOps, (60%) and conferencing/collaboration (51%).

    Chris Garvey, executive vice president of product for 2nd Watch, said the report shows that not only are more large enterprises accelerating cloud adoption, but the projects being launched are also more strategic to the business.

    The survey finds 60% of respondents said they are prioritizing projects with potentially large payoffs over cost-conscious projects. Nearly half (47%) said now is the time to position their company for the long haul, while 39% said they are accelerating the use of the cloud to deliver digital products. As part of those efforts, more than a third (34%) said they are accelerating the migration of applications to the cloud.

    A total of 93% of respondents use at least two cloud platforms, with Microsoft Azure being the most widely employed.

    Cloud computing platforms, however, are not without their challenges. Most respondents (82%) said they’ve experienced cloud-related challenges, with 77% reporting those issues have caused them to alter their cloud strategies. Nearly half (46%) said experiencing cloud security-related challenges, while 48% said cloud computing turned out to be more expensive than initially anticipated.

    The top challenges identified are providing remote workers access to corporate systems (63%), providing remote worker support (57%) and conferencing/collaboration systems that haven’t worked as expected (47%). Half said they are accelerating the use of the cloud to support remote employees, with 58% expecting at least half of their company’s employees will become full-time remote workers in 2021.

    Overall, nearly two-thirds (64%) said their IT related budgets have stayed the same or grown since COVID-19 began, and 59% said their cloud budgets would increase over the next 12 months. A total of 80%, however, acknowledged they are concerned COVID-19 will continue to impact their IT strategy and only half (50%) said they were confident in their organization’s ability to adjust.

    Primary areas of focus over the next 12 months include databases (42%), internet of things (39%), data warehousing (35%), artificial intelligence/machine learning (34%) and data lakes (26%).

    Garvey said large enterprises are clearly looking to take advantage of their deeper pockets to accelerate digital transformation initiatives at a time when smaller rivals may not be able to invest. However, because the pandemic has impacted some verticals more adversely than others, the level of digital business transformation occurring across different vertical sectors is uneven, he noted.

    It may be a while before the winners and losers are identified in the wake of the pandemic. However, it’s clear large organizations are betting on IT now more than ever to differentiate themselves. As large organizations assess the damage from the pandemic, it’s likely that the future of many of these companies will depend on the degree to which they can adopt a wide array of not just emerging technology platforms, but also the processes required to master them.

  • TechStrong TV: ‘The Startup Community Way,’ With Brad Feld

    TechStrong TV: ‘The Startup Community Way,’ With Brad Feld

    Brad Feld, co-founder of Foundry Group and Tech Stars, recently joined us on TechStrong TV to talk about his new book, co-authored by Ian Hathaway, “The Startup Community Way.” Brad is one of my oldest friends and has a lot of great insight into the tech community and the shift in the balance of power in many organizations, and his latest book discusses that at length and more.

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

    Transcript

    Alan Shimel: Hey, everyone, thanks for joining us on this segment for TechStrong TV. I am, like, thrilled beyond thrilled to be joined by an old friend of mine—not that he’s old, but we’ve known each other a very, very long time—my friend, Brad Feld, who really needs no introduction in any kinda tech kinda discussion. Hey, Brad—welcome.

    Brad Feld: Alan, it’s great to be here. Awesome to see you.

    Shimel: It’s awesome to see you, my friend. I haven’t seen you in too long, and I don’t know when I’m gonna see you in person again with the current state of affairs, but I hope it’s soon.

    Feld: I get virtual Alan and you get virtual Brad.

    Shimel: That’s the best that we’re gonna have to do. So, Brad, we have you on here today because your book came out, I guess it was last week it came out officially, right? And it’s called “The Startup Community Way.” It is a sequel or follow on to “The Startup Community” book that you originally authored how long ago? That had to be, what, seven years ago was the first book?

    Feld: Yeah, “Startup Communities” came out in 2012, and along with the publication of “The Startup Community Way,” we came out with a second edition of “Startup Communities” that has some updates to it and some things that I got wrong the first time around fixed. So, it’s nice to freshen up.

    Shimel: Well, we’re gonna talk about those. Yep, and we should mention, Brad, that you have a coauthor in this “The Startup Community Way” book, and that’s Ian Hathaway. And Ian may be less entrepreneurial or less experienced in the VC entrepreneur world, but very experienced in research and kind of doing, you know, looking at this scientifically, if you will.

    Feld: Yeah, he was a really good coauthor, he’s become a close friend, and part of the thing that was good about it was, we do have different frames of reference. So, as we talk through and work through the book and work through different ideas around the book, you know, pressing against each other from different frames of reference really generated, I think, much better ideas and much better writing.

    Shimel: Excellent. So, Brad, I’m gonna make some assumptions, here. First of all, our audience is a very geeky, techy audience, right? We cater to digital transformation, DevOps, cloud-native, open source kinda stuff, and of course, cyber. They know who Brad Feld is. They’re familiar with tech stars, they’re familiar with startups, they’re probably even familiar with the term startup community, which you kinda initially coined with the book, right? So, I don’t want to spend all of our time sort of laying that foundation. They’re familiar with who Brad Feld is as well.

    And if you’re not, I’m gonna tell you really quick. I sold my first company to Brad in 1997. He’ll tell you I was wearing a stupid sports jacket, but we’re not even gonna talk about it. [Laughter] He’s been at SoftBank Venture Capital, Mobius, Foundry Group, started Techstars, one of the kind of forces behind—how do you pronounce it? National Nitwit is—what does it stand for, Brad?

    Feld: NCWIT, National Center for Women in Information Technology.

    Shimel: Yep, and, you know, one of my favorite things you’ve done. But, I mean, beyond—we could go on and on, but let’s not. Brad, I started reading “The Startup Community Way,” and I have some issues, questions, areas I want to jump in on with you if it’s okay.

    Feld: Sure. So, obviously, with your initial “Startup Community,” you had what you coined the Boulder Thesis, and there were four main points in the Boulder Thesis. Number one, though, and sort of primal to me was that, for startup communities to thrive, they need to be led by entrepreneurs, right? These entrepreneurs had to have a long-range kinda commitment to the community, and let’s stop right there for a second.

    Shimel: I noticed in this, in the new book, you kind of made a realization that, in informing that, we set the entrepreneurs up as sort of the alpha predators, as the top dogs on the food chain, right? But in doing so, it might have created a little bit of us versus them between entrepreneurs and the other, I’m not gonna say equal participants, but vital participants in this equation of a startup community. The workers of these companies who go to work at entrepreneurs, universities, government agencies—the community, right? It’s not just entrepreneurs.

    And I think one of the things you’re seeking to address in the book is to kinda ease that tension, the us-versus-them tension, correct?

    Feld: Yeah, that was a mistake I made in the first book, and it was a mistake of language, not of intent or description. So, in the first book, I made the strong assertion that the leaders of a startup community have to be entrepreneurs and, in the absence of a critical mass of entrepreneurs playing leadership roles, your startup community won’t grow and evolve.

    I then labeled everyone else a feeder, and my intention was not to have leaders be one up on feeders—you know, one up, one down relationship—but just different. And I tried to categorize them differently and spent a fair amount of time in the book describing what leaders do and what feeders do. And the miss was, there’s a lot of people who play leadership roles in startup communities who are not entrepreneurs, and in the new book—and I also went back and updated the second edition of the old book—I now call them instigators. And the idea of an instigator is that they are playing a leadership role in the startup community, and that’s a very powerful notion.

    So, essentially, people now are classified as leaders and instigators, and the organizations are feeders, and that’s really important, because the organizations tend to be hierarchical. They tend to have their own agenda in addition to the agenda of the startup community. And the fundamental goal of a startup community, pure and simple, is to help entrepreneurs succeed. And the feeder organizations, part of their goal as organizations are to help entrepreneurs succeed, but that’s not their only goal.

    We also distinguish now between the notion of a startup community and an entrepreneurial ecosystem. A startup community, at its core, exists to help entrepreneurs succeed, and an entrepreneurial ecosystem has, at its core, a startup community, but it’s a much bigger thing, and it engaged all of these other organizations around their goals and how they engaged with entrepreneurship.

    So, I think we’ve done a better job in “The Startup Community Way” of talking about leadership and who provides leadership and the people providing the leadership in the startup community being both the leaders, the entrepreneurs, and the instigators, people who aren’t entrepreneurs, but who are playing a leadership role. And then the organizations, the other actors who contribute to the startup community but don’t control it, don’t try to organize it, don’t try to run it, just participate in it.

    Shimel: Excellent. You know, Brad, there’s a lot of analogies there to what we see in the DevOps world, right? The developers have become the entrepreneurs of the first edition of startup community, where it seems the rest of the DevOps ecosystem revolves around these developers, and look, developers are impossible to hire. They’re, as you know from your companies, they demand a lot of money, they want a lot of say over their environments, their culture, and everything else. They’re kinda calling the shots, and the rest of the world kind of revolves around it.

    But also, a lot more is thrown on these developers’ shoulders in terms of what—they’re no longer responsible just for code, they’re responsible for deployment, they’re responsible to make sure the testing is right, you know, for that whole software factory. They, in essence, run the factory. And a similar kinda thing has happened in DevOps where we say, “Hold on—yes, the developers’ role is a very important role, but so is that of the cyber person, so is that of the SRE, so is that of the tester. And literally, it does take a community, and it’s caused a bit of a realignment, if you will, within how we look at DevOps and cloud native and continuous deployment.

    I wonder, you know, carrying that analogy out, Brad, though, I think a lot of our audience out here, they tend to interchange entrepreneur with technical entrepreneur, and I wanted to talk to you about the role of the business entrepreneur for my own selfish reasons, but you know—and you have a ton of experience on this. When we talk about entrepreneurs, Brad, how much of it is, you know, so a technical entrepreneur, the kind of person who goes on to be the CTO in their startup or in their company versus people who come from the business side of things, right? And what’s the right mix, or what’s a—I don’t know if there is a right mix, but what’s the right formula for when we look at the entrepreneurs within the greater entrepreneurial ecosystem, within the startup community, between technical entrepreneurs and, let’s call them, business-orientated entrepreneurs? Make sense?

    Feld: Well, they’re both—it makes total sense. They’re both essential. And when I talk about entrepreneur, I don’t really distinguish between the two. I think there are many different roles that founders or entrepreneurs play. And, for a lot of people, the word entrepreneur tends to be triggering. Like, it used to be something that was very well understood.

    Today, the word entrepreneur gets used, I would say, almost indiscriminately in a lot of different contexts. And, to your question, I would come back to the notion specifically of a founder. A founder of a company, somebody who is one of the people who helps create the company from the very beginning, and you need a combination. You need technical founders, technical entrepreneurs. You need business founders, business entrepreneurs. Most companies generally have more than one co-founder, but there are definitely successful companies with one founder.

    But generally speaking, if you have more than one founder, especially if you have a combination of a business founder and a technical founder, you can make a lot more progress a lot quicker in many cases. And if you have three or four founders, I generally try to encourage people to have at least an equal number of technical founders to non-technical founders, and preferably, more technical founders than non-technical founders. And, you know, Alan, you’re humble. I mean, you talk about yourself as the business guy, but you have very, very deep technical experience at this point. Even when I met you when you were running your first company in the late 1990s, you had deep technical experience.

    So, the technical founder doesn’t necessarily mean just somebody who writes code, and I like to shift the language to be product-oriented instead of technical. So, if you think about three founders, three co-founders, the idea that two of them are focused on product and one of them is focused on the business, and the product and the business obviously overlap with the customer, and so, all three of the founders are paying attention to the customer, the evolution of what you’re trying to do from the very beginning can move a lot quicker.

    By the way, there are a lot of very, very good technical founders who also have strong business sense in the same way that you’re a strong business person that also has strong technical sense. So, it’s not cut and dried, and you’re not like, “Oh, I’m in this box and you’re in this box.” I try to encourage entrepreneurs to think more broadly about what they’re doing and how they’re doing it.

    Shimel: Excellent. Hey, I’d like to shift a little bit away from the entrepreneur because they get all the press, anyway. I want to talk about something that was really highlighted in your book, and that is the role of, within the community, within the ecosystem, the role of universities and the role of government, the role of these hierarchical groups as you referred to them.

    Let’s talk a little—and I’m gonna bring it home to what I see here in South Florida, for instance, but Brad, you know, (a) it’s an important role they played in this big picture, but what optimally, what can the government do optimally, for instance, to help you—there’s federal, there’s state, there’s local—you know, where do you see it?

    Feld: You have to be somewhat granular, and you also have to be focused on the specific place that you’re at, whether it is local, state, or federal or national governments. Interestingly, in the first book in 2012, I basically punted on this issue. I said, “The best government can do is do no harm to the startup community.” And, you know, I would say that was a combination of me not really having a particularly clear view of what government could have along with me kinda punting and being lazy about digging into it—based on my own experience, my own experience in Boulder, for example, is that the local government basically pays no attention to entrepreneurship and doesn’t really understand how to engage it in an effective way.

    The state of Colorado government, actually, has done a pretty good job, and there have been a number of things over the years that the state of Colorado has done around this and then, you know, our federal government in the U.S. ebbs and flows. Sometimes there are some programs that are incredibly helpful and oftentimes, there are things that either get in the way or are counterproductive.

    So, I’ve come to a place where what I think is important for government at any level to start with is to understand what their goal is. And I’m gonna come back to this statement I said earlier, which is, the goal of a startup community is to help entrepreneurs succeed. So, if government wants to engage in the startup community, their goal should be to help entrepreneurs succeed.

    Now, at a local level, that often means that the best way to do it is an instigator—gonna use that word again—who is a person who works for a local government who actively engages as a leader in the startup community. So, they’re not actually bringing government so much to the startup community, but they’re, in their role in government, they may have a full-time job to help with economic development or developing the entrepreneurial ecosystem or whatever it is. Like, their first step should be to become part of the startup community as an instigator rather than show up as government and say, “Hi, I’m from the government, I’m here to help.”

    Shimel: Mm-hmm.

    Feld: One of the things the government really struggles with is allocating capital. Government has a lot of capital, as we’ve just learned from the COVID crisis. You know, overnight, the federal government allocated or deployed $2 trillion, and it looks like it’s gonna allocate another $1 trillion across their society. And a lot of that money went towards helping, quote, small business, where government thinks of small businesses and entrepreneurial businesses as the same.

    If you use that lens, though, and you look at how that money was allocated, it was primarily allocated through two vehicles, PPP loans and EIDL loans. It was incredibly inefficiently allocated, and as a result, some companies got financial support, others didn’t. And it was done in this very, very sort of explosive way that may have had some very powerful short-term impacts, but it’s unclear on whether it has medium or longer-term impacts.

    One last sort of comment on governments, state [Audio skips] governments over and over again. We need more venture capital here, we need more capital here, and we need to do things to get more capital here. In “The Startup Community Way,” we actually defined capital as having seven different flavors, where financial capital was one. Because generally when people talk about capital, they’re talking about money, and this is another place where governments can really help is to think about what capital the startup community already has that’s not financial capital—what kind of intellectual capital, what kind of network capital, what kind of infrastructure capital exists and what more is needed. And then try to figure out how to use the resources of local or state government to amplify those types of capital that ultimately then is a positive reinforcing loop to attract other sources of capital.

    So, unfortunately, it’s—I think, for government, it’s nuanced, and a lot of times government is looking for a playbook and a solution, like, “I just need to do the following four things and then good things will happen.” And this is essential to “The Startup Community Way” where we talk about startup communities now as complex systems.

    Shimel: Yeah.

    Feld: And one of the things that many organizations have a lot of trouble interacting with—especially government, but not exclusively government—is complex systems.

    Shimel: So, let me talk a little bit about complex systems here in South Florida. I know you’ve been down in Miami a few times, you’ve had a chance to see sort of the Miami startup scene and, you know what, in four or five short years, it’s actually come a long way. You know, it’s the gateway to Latin America and they talk about all that, but more importantly, there are some really concrete programs, the Knight Foundation, a few other organizations as well as local government has instituted it, and we’re beginning to see a startup community take hold there, in my opinion. It’s not bolder, it’s not awesome, but it doesn’t have to be, it’s Miami, and it does it in its own unique Miami way.

    But South Florida is more than Miami, right? You basically have a tri-county or three city sort of metro area of Miami, Fort Lauderdale, and West Palm Beach. Taken together, I forget if it’s the six or seventh largest metropolitan area in the U.S., right, between these three counties—Miami-Dade, Fort Broward, and Palm Beach County. A tremendous amount of universities, we haven’t even talked about universities yet, but we have University of Miami and FIU and FAU here. Lots of universities—universities that are, you know, in your first book when you talked about the role, you know, they do serve as anchors.

    I think what holds us back in the South Florida area, though, Brad, is that we have shoguns, right? I remember when your business card used to shogun, remember those days? [Laughter] But we have shoguns here every 10 or 15 miles, each little town or incorporated village is afraid that the next one is gonna do more, better than them.

    Here in my little neck of the woods, Boca Raton and Delray Beach constantly—they’re right next to each other—constantly banging heads. Boca has the universities, maybe a little more capital. Delray has a great sort of startup scene brewing and they do have local economic development and a number of co-working places and stuff like that. But they can’t seem to get their act together to work—and these are just two little, piddling towns, to tell you the truth, right? If they would put it together, they might have something—but they can’t, they’re too busy competing. And it’s the same thing up and down this coast, right?

    So, you have an area with a lot of universities, a lot of capital, a decent amount of tech talent—I mean, not deep enough, by any means—and certainly, many entrepreneurs. But they’re at loggerheads. How do you—in creating this entrepreneurial ecosystem, how do you overcome this sort of petty jealousy, these shoguns fighting for supremacy?

    Feld: Well, you have to start from a perspective of playing a positive-sum game, and what you’re describing is a classic zero-sum game, where there’s winners or losers.

    Shimel: Yep.

    Feld: And, you know, the ones that we’re used to in terms of zero-sum game and election is a zero-sum game, somebody wins, somebody loses. Sports of events, most of them, zero-sum game—winner, loser, sometimes you tie if you play soccer. But, you know, for most games, there’s a definitive winner or loser. You don’t wanna play a zero-sum game

    You wanna play the opposite of that, which is a positive-sum game where the cliché would be a rising tide lifts all boats, right? You’re helping each other over time sort of building something that’s more and more successful. And, in defining startup community, you can define startup community however you want in terms of geography. You can define it in a little town like Boca or Delray. You can draw a bigger circle around it and call it the Greater Miami Metro Area or whatever you wanna call it.

    By the way, you said something earlier that’s really important is that you don’t need to create or emulate somebody else. Boulder is Boulder, Miami is Miami, Greater Miami is Greater Miami, Boca is Boca—like, you already have an identity as a city. But the key is to try to work with the people who are close to you to build a broader and more robust startup community. And, interestingly, if you’re taking this approach and playing a positive-sum game where you help each other versus you compete for resources and you compete to win or lose in sort of an inappropriate way or an unhelpful way, it doesn’t really matter.

    The very specific example I’d give you is that, does it cost anything to travel from Delray to Boca? Do you have to pay—

    Shimel: You could walk.

    Feld: – you could walk, right? You don’t have to pay a tax, you don’t have to have somebody, you know, stamp your passport to get from one place to another. I mean, you really are part of a—

    Shimel: Not yet.

    Feld: – not yet. You’re part of a collaborative collection of people, and the goal should be that you wanna encourage cross-fertilization between these communities and you wanna encourage amplification of what’s going on and get critical mass around it.

    Now, there’s nothing wrong with local pride, and I can use Boulder and Denver as really good examples of that. Boulder and Denver are both very, very vibrant cities. Boulder is 100,000 people, Denver is 2,000,000 people. They’re about a 30- to 45-minute drive apart from each other. They have independent identities, but there’s an enormous amount of collaboration between the two, and that’s very, very, very powerful.

    Shimel: I mean, so, I’ve done Meetup groups in Denver and Boulder. You know, we started one with the Jump Cloud folks called IT as Code. The first meeting was down in LoDo. But we had people from all over, from Boulder and everyone else drive in, and we had a great meeting at one of the breweries there—good times.

    I’ve started a bunch of Meetup groups here in South Florida, and we’re constantly, “Jeez, we have to do this one in Miami for the Miami people. We need to be down near Fort Lauderdale-Hollywood this time, or out at the university out West there to attract that Broward crowd.” There isn’t that sense of community that the rising tide lifts all boats, and I’m hoping that books like “The Startup Community Way” kind of make their way into the stream here, the mainstream of what these people are thinking about.

    We even see it, Brad, with—so, we have the South Florida Technology Association, then we have the Palm Beach Technology Association. There’s several counterparts in Miami. They even compete at such a—and it’s a petty competition, frankly.

    Feld: Well, they could really change the game in the region by deciding to collaborate, and they can have separate organizations with separate memberships and separate goals even if they’re in the same place because there’s no need for there to be one monolithic thing. In fact, you probably want a bunch of different things. But instead of viewing it as an, “I win, you lose,” they’re all trying to help entrepreneurs succeed. And in the context of that—again, the instigators, the leaders of those organizations, right, those organizations, even if they’re comprised of entrepreneurs, they’re still feeder organizations, right? The organization themselves is a feeder supporting entrepreneurs. The people in those organizations who are playing leadership roles can play a leadership role in the startup community, which is separate from their organization. Their organization is not the thing that’s organizing, managing, running the startup community. It’s just another participant in this.

    And so, changing that frame of reference for humans is hard, because we’re used to competing, and you know, we’re—

    Shimel: No, it’s like “The Highlander”—there can be only one. [Laughter] Right? And it’s a problem—I get it.

    Feld: Well, and changing that is important and, you know, it’s one thing to say it’s important to change; it’s another thing for a bunch of leaders in a startup community to say, “You know what? Enough of this. We don’t need the segmentation, we don’t need the competition. Let’s all pull together even though we’re addressing different things, and we have some overlap. We’re trying to do something together that makes our place better.”

    Shimel: Fantastic. Brad, we’re almost out of time. I wanted to leave you a couple minutes at the end here for our audience watching. If you had the three biggest takeaways from the book that you want people to go home with, what would you say they are?

    Feld: The first is the distinction between a startup community and an entrepreneurial ecosystem and the reinforcement that the goal of the startup is to help entrepreneurs succeed, and you can define everything from there.

    The second is that a startup community is a complex system, and in a complex system, there is no deterministic outcome. There is no playbook. There is no set of rules to get from Point A to Point B. A simple system would be making a cup of coffee. You put beans into the machine, you get coffee out. It might not be a good cup of coffee, but it’s a cup of coffee.

    Shimel: Coffee it is.

    Feld: Coffee it is. A complicated system would be manufacturing a Boeing 787 airplane. Once it’s designed, the rule book’s now really big, but you put parts at the beginning and at the end comes out a Boeing 787.

    A complex system would be raising a child—and you’ve raised two. And you know that on day one of the child, what you tell the child to do and what you aspire for the child to do at age 21 is not what’s gonna happen. Every little thing you do, the child evolves and changes and grows and develops and all that stimuli is positive and negative along the way. And at the end, the child is whatever the child is. But it evolves in a way that you can’t predict. That’s what a startup community is—you cannot predict what that outcome is and you can’t control the outcome.

    The last—and we cover this in the book and there’s several examples. I gave one which was the notion of capital not just being money and defining it as the seven capitals instead of just financial capital. Another would be something we could call the measurement trap. Everyone in a startup community feels the need to measure things, and this is especially true for government, this is especially true for nonprofits like the different associations that you probably described.

    They’re measuring constantly—number of companies created, number of unicorns, dollars raised, number of jobs. These are things to measure, but they’re not the important things, they’re the easy things. And the really important thing that happens in the growth and development of a startup community and complex system is not the parts, not creating more pieces, it’s the interaction between the pieces, interaction between the parts. And measuring that interaction is really, really difficult, but that’s where all the power comes from.

    Shimel: Got it. Love it. Hey, Brad, first of all, thank you so much. I know you’re crazy busy with promo-ings on the book and everything, so thanks for taking the time to come join us here on TechStrong TV. Best of luck with the book. We should mention it’s available on Amazon, it’s on all the usual places where one buys books today. Not going to book stores very much, unfortunately, but yes. So, it’s “The Startup Community Way,” Ian Hathaway, Brad Feld—check it out. It’s available in Kindle and hardcover at this point. I don’t think a paperback is out yet, right?

    Feld: No paperback yet, just Kindle.

    Shimel: Yep, hard book and Kindle. I have it on my Kindle here, I was all ready with my notes—but Brad Feld, author, “The Startup Community Way,” Foundry Group, Techstars, tech entrepreneur extraordinaire, and one of my best friends for a long time.

    Feld: Thanks for doing this, it’s so awesome to see you, and congrats on everything you’re doing with your business now. It’s wonderful to see it.

    Shimel: Thank you.

  • 3 Key Issues With Hybrid Cloud Transformation

    3 Key Issues With Hybrid Cloud Transformation

    The cloud has fractured. Nowadays, it is nearly impossible to scale a cloud-agnostic digital transformation initiative. The reality is that most enterprises adopt a hybrid cloud arrangement. Whether designed strategically or throughout years of competing vendors and technology influences, hybrid cloud environments, and the problems therein, seem a mainstay for modern IT.

    Many digital transformation efforts are culminating in hybrid cloud scenarios. 451 Research recently found 72% of enterprises are already using more than one cloud vendor. As one can surmise, competing standards and inconsistencies among cloud tooling can cause headaches for developers, security teams and potentially even end users.

    3 Common Cloud Transformation Problems

    I recently met with Jeff Kukowski, CEO, and Grant Ho, CMO at CloudBolt Software, to identify issues within today’s cloud transformations. According to CloudBolt, custom coding, governance concerns and cybersecurity incompatibilities are among the top problems that hold back cloud transformation (or make it very costly). Below, we’ll see what strategies they recommend to solve these problems.

    1. Custom Coding

    In 2020, a software-defined approach seems the obvious preferred choice for most IT professionals. Yet, custom code is still a significant struggle for hybrid clouds. The Standish Group research shows 19% of projects will be canceled before they ever get completed. Further results indicate 52% of projects will cost 189% of their original estimates. Custom code decreases reusability and creates redundancy.

    2. Lack of Governance

    With many disparate cloud applications, it can be difficult to set standards. There is not much control. This free-for-all can directly impact the business. Lack of visibility into resources, a related concern, could cost a business significant expenses. Citing a recent Gartner study, ParkMyCloud estimates that companies waste $8.8 billion on idle cloud resources each year.

    3. No Role-Based Security Policies

    Gartner found that 33% of enterprise security attacks are happening from people using resources in the cloud and not necessarily putting the proper governance and security parameters in place. Without role-based access control (RBAC) and a standards-based way to apply RBAC across all your resources, hackers can more easily penetrate a hybrid cloud.

    How Hybrid Cloud Affects DevOps

    These above problems are quite broad, but they reflect a culmination of many roadblocks along the development pipeline. In terms of DevOps, juggling the ever-growing variety of hybrid cloud tools could easily stunt deployment velocity.

    Kukowski described how cloud IT faces a plethora of tooling styles. They include on-premises tooling, serverless, infrastructure as code, Terraform, Kubernetes and backup as a service. “Greater than 70% of organizations are not only multi-cloud, but they are multi-tool,” he estimated.

    Naturally, supporting nuances between them becomes tricky. Not only must you recognize governance and security inconsistencies between platforms, but you must maintain them “into Day 2,” he said.

    Solution: Policy-Based Automation

    With hybrid cloud tooling now a reality for most enterprises, managing them becomes the next logical step. Solutions primarily revolve around better automation to increase self-service capabilities. For Kukowski, the answers lie in automated governance, heightened tooling visibility and implementing enterprisewide security policy services to automate security compliance and decrease custom coding.

    One way to achieve these benefits is by utilizing a Cloud Management Platform (CMP). Gartner’s 2020 Magic Quadrant for Cloud Management Platforms includes CMPs from CloudBolt, Embotics, Flexera (formerly RightScale), HyperGrid, Morpheus Data, Scalr, and VMware with vRealize Automation Cloud plus CloudHealth. A CMP layer could help automate self-service IT, assisting engineers to do their work with governance and security capabilities in place.

    Using a CMP, companies could eliminate custom coding for things such as access control. Such increased visibility could, for example, significantly decrease AWS server cost by reducing unused deployments. A CMP can benefit CI/CD too. Home Depot, for example, uses a CMP to greatly improve efficiency, decreasing infrastructure deployment time from weeks to hours.

    “Who is authorized to perform that action, on that K8s container, local VM, or cloud machine? We need visibility into that,” Kukowski said. “What is it doing? When is it running? Who has visibility to shut it down?” He recognizes that deep industry expertise is required to abstract complexity and standardize governance across all these situations.

    Streamlining the Polymorphic Cloud

    Saturated within an overabundance of cloud tooling, it’s easy to lose sight of your enterprise’s IT policies. Without global DevSecOps standards, security for hybrid cloud becomes risky.

    Enterprises with multi-tool environments are also at risk of wasting development time and effort. “We want to make sure the market does not repeat the problems of the past,” Kukowski noted. “Why custom code the fundamentals that operate your business?”

    Instead, companies should seek to reduce redundancy and eliminate custom code for each point to point integration. However, abstracting such complexity involves porting governance standards across all environments—a challenging feat for internal teams.

    The solution could lie in utilizing an external CMP layer. Such a layer could offer a software-defined approach to eliminate custom coding, offering policy-based security controls that consider the organization’s needs.

  • Serverless Computing: Taking DevOps to the Next Level

    Serverless Computing: Taking DevOps to the Next Level

    Serverless computing enables you to outsource information, thus freeing teams to focus on front-end work. Organizations choose serverless when they look for faster and easier ways to release updates and patches. DevOps teams often use serverless when they are looking to automate infrastructure tasks. However, each provider offers different capabilities, and each service does require a level of training pre-adoption.

    What Is Serverless Computing?

    Serverless computing is a method that outsources infrastructure and infrastructure tasks to external providers. Organizations choose serverless computing because it enables development and operations teams to focus on the front-end of products and services.

    There are a few traits that distinguish serverless infrastructures from traditional cloud automation models:

    • Serverless computing services eliminate user responsibility for the management or operation of infrastructure.
    • Serverless computing services enable users to run code on-demand according to requests or event triggers. Infrastructure use scales transparently based on how many requests or events occur.
    • Serverless computing is pay-for-use and can be used to ensure that users pay only for actively used resources.

    The benefits of serverless in enterprise environments include:

    • Better control over production deployments.
    • Faster and easier updates or patches.
    • Increased productivity and easier release rollouts.

    Popular Serverless Computing Services

    All three major cloud providers offer serverless computing services. Below you can learn about these services and how each operates.

    AWS Lambda

    AWS Lambda is a service for serverless computing with other AWS services or via API. It can be connected to applications or run as standalone code. When using Lambda, users pay for active compute time although instances can be reserved to ensure their code runs with menial latency.

    Lambda can be triggered by a variety of AWS services, including Kinesis and DynamoDB. It can be monitored through Amazon Cloud Watch. Common use cases for Lambda include data processing, stream processing, machine learning and application backends.

    Azure Functions

    Azure Functions is Microsoft’s serverless service. You can use it for end-to-end development, including building, testing and deploying code. Functions can be used with a variety of Azure services and integrate with Visual Studio and Visual Studio Code for easy use.

    In addition to Functions, Azure offers Logic Apps, a service for creating visual design workflows and orchestrating Functions activities, and Event Grid, a message routing service to integrate Functions with other Azure services.

    Google Cloud Functions

    Cloud Functions is Google Cloud Platform’s functions as a service (FaaS) (i.e. serverless) offering. It can be used in the cloud or with hybrid deployments and it includes built-in monitoring, logging and debugging features.

    Cloud Functions supports a variety of environments including Cloud Run, Kubernetes and other Knative-based environments. Use cases for Cloud Functions include integration with third-party services, application backends, real-time processing, virtual assistants and machine learning.

    Why Serverless for DevOps

    If you are already using a DevOps approach or are considering adopting one, serverless can be a good option. Many DevOps teams, especially those operating in the cloud, are already working with modular components managed via a pipeline. Moving these modular services to serverless can enable teams to eliminate some of the tasks related to pipeline management and focus on development and deployment.

    This capability is especially valuable for teams that are just getting started or are looking to switch to DevOps practices. Serverless systems can enable teams to get started with development and testing right away on a comfortable scale. Then, as productivity increases, the serverless infrastructure can smoothly scale with minimal to no effort on the part of operations.

    Another benefit of serverless infrastructures is the ability to easily enable DevOps automation. With serverless, you can deploy your pipeline without hosted solutions. You are only responsible for “glue code.” This infrastructure is flexible and you can easily modify it as needed using infrastructure as code (IaC) solutions and automated events.

    Despite these benefits, there is a potential downside to serverless. Your DevOps team does not have the same visibility into or control of the functioning of the infrastructure. While you can integrate monitoring, teams are limited in how much of the infrastructure can be customized or manually affected.

    How Serverless Can Take DevOps to the Next Level

    There are several ways serverless deployments can be leveraged to improve DevOps productivity. Below are a few examples to consider.

    Infrastructure as Code

    Provisioning infrastructure is often a significant portion of deployment processes. Many applications use a variety of serverless services as building blocks through all stages of development and release. Making sure that these services are correctly connected and configured is key to a successful deployment.

    IaC can help users accomplish these tasks smoothly by leveraging declarative languages and tools such as Terraform. With these solutions, users can version your infrastructure along with their code, keeping tasks in sync and deployments consistent.

    Flexible Deployments

    With serverless services, infrastructure is immutable. Any changes result in new instances being spun up and activated. This means both old and new versions can run simultaneously.

    This immutability can be used to perform flexible deployments that are not possible or are much more difficult with traditional infrastructures; for example, canary or blue-green deployments. With serverless infrastructure, users can switch from one version to another with minimal fear of service interruptions and the ability to easily rollback updates.

    Distributed DevOps

    Serverless services can enable DevOps teams to work across a variety of environments and locations with minimal impact on others. These services allow the distribution of workloads at scale and can ensure that infrastructure is always available.

    The catch is that greater distribution and the ephemeral nature of serverless can make infrastructure much more difficult to monitor effectively. To account for this, teams need to ensure centralized monitoring with real-time alerts. Teams should also periodically audit infrastructure availability and performance to ensure that resources are functioning as expected.

    Conclusion

    Serverless computing enables DevOps teams to eliminate time and cost on the back end. Each serverless provider offers different services that can help achieve different capabilities. The main capabilities are provided via the use of functions, which enable the automation of infrastructure. However, in most cases, teams do need to learn how to use functions to properly configure customized IaC workflows. Once teams understand how to use the software, they can create flexible deployments and a distributed DevOps pipeline.

  • IaC and Kubernetes: A Natural Pairing

    IaC and Kubernetes: A Natural Pairing

    Using IaC with Kubernetes helps standardize Kubernetes cluster configuration and manage add-ons

    Infrastructure as code (IaC) is the ability to provision and manage infrastructure using a configuration language. It offers repeatability, transparency and the application of modern software development practices to the management of infrastructure including networks, load balancers, virtual machines, Kubernetes clusters and monitoring.

    IaC helps to reduce error and configuration drift while allowing engineers to spend time on higher-value tasks. IaC defines what the end state of infrastructure should look like, instead of defining a process to be executed.

    So Why Aren’t All Companies Using IaC?

    There are three main reasons why companies may not yet be embracing IaC.

    Many industries and engineers have not fully embraced or adapted to the paradigm shift of infrastructure APIs and code

    A lot of us think about infrastructure as touchable, involving physical installation and cabling. It’s only relatively recently in enterprise IT years that the industry has adopted APIs that allow borrowing and configuring infrastructure on-demand without the physicality. Engineers are good at standing up infrastructure using a time-tested, battle-hardened process. Incremental learning and integrating IaC into processes and culture helps to digest an otherwise daunting and challenging project.

    Industries are hard at work adapting security controls and regulations to incorporate the opportunity of cloud and automation without compromising high standards for privacy, safety and security. Engineers using IaC to improve their own efficiency can help champion its use in wider circles. One such example of this success is the 18F office which helps improve how the government serves the public through technology.

    IaC may feel like a loss of security or control

    Increasing the awareness of how and why infrastructure is configured can invite questions or feedback that initially may feel uncomfortable to those who have made infrastructure decisions. The ease with which others can make changes to infrastructure may feel dangerous or devaluing to engineers who have always pushed those buttons.

    IaC provides an opportunity for improving single human points of failure and knowledge bottlenecks without jeopardizing necessary controls. Access to infrastructure code and IaC tools can still match organizational structure, culture and approval processes. Infrastructure engineers remain integral to its evolution and success, and they are more available to tackle next-level problem-solving.

    ‘We move too quickly to take the time to ramp up with IaC, and we’re fast at clicking in user interfaces’

    The repeatability achieved by IaC means artisanally created infrastructure does not need to be kept around because it may be needed next month and parallel infrastructure can be created for testing and destroyed tomorrow. Start using IaC for something small such as spinning up that occasional temporary VM, then create a limited-access service account that someone else can use along with your IaC when they need that VM. Your IaC efficiency will grow with your organization’s body of IaC knowledge and code.

    Kubernetes and IaC

    Using IaC with Kubernetes helps standardize Kubernetes cluster configuration and manage add-ons. Infrastructure now can be versioned and committed to a Git repository, and it can more easily be “stood up” elsewhere when the company needs to expand to new regions or clouds. IaC benefits are vast and include:

    • Reduced human error and increased predictability: Create new test environments without impacting production and make changes across multiple environments using code review processes. Focus and attention to detail are less impacted by repetitive manual work.
    • Consistency: The repeatability of IaC with Kubernetes allows for the rapid creation of consistent infrastructure. This frees up time to address other challenges.
    • Improved changed tracking and auditability: When infrastructure is represented in a versioned repository such as Git, commits to the Git repository can reflect who, when and why changes were made. The code provides a record of how environments were built and evolved.
    • Faster speed to recovery: The reliability of an application is impacted by the ability to pivot and the speed to redeploy. Infrastructure as code can help you know what the recovery process looks like and practice that process more often.

    Start Using IaC and Kubernetes

    As a company moves into the world of containers, cloud-native apps and Kubernetes, IaC will help teams improve application reliability and stability, streamline development and operations and support a better user experience.

    In a Kubernetes environment, reliability becomes much easier to achieve with IaC because teams are deploying standard configurations. DevOps teams can use IaC to embrace the ephemeral nature of containers and Kubernetes pods, as well as avoid single points of failure.