devopsy.kinsta.cloud

Category: Blogs

  • Stacklet Embeds Collaboration in Compliance-as-Code Platform

    Stacklet Embeds Collaboration in Compliance-as-Code Platform

    Stacklet has added collaboration capabilities to its security and compliance platform that automatically groups related notifications, routes them to the right stakeholders and integrates with existing workflows and collaboration tools.

    The Stacklet platform is based on Cloud Custodian, an open source project that provides access to a domain-specific language that enables an IT team to employ YAML files to manage compliance-as-code.

    Stacklet CEO Travis Stanfield said that approach makes it simpler for organizations that have embraced DevSecOps best practices to comply with a wide range of mandates by shifting responsibility for achieving compliance further left toward DevOps teams.

    The latest version of the Stacklet Platform adds communications capabilities that leverage cloud resource configuration and policy metadata to automatically route notifications and escalations. Customizable notification templates add context for teams to collaborate either via email or integrations with Slack, Microsoft Teams and Symphony instant messaging. The Stacklet Platform can also trigger external workflows in tools such as Jira and ServiceNow to track issue resolution and generate reports.

    Ultimately, the goal is to make it simpler for IT teams to prioritize their compliance remediation efforts by keeping everyone involved continuously updated, said Stanfield.

    The number of compliance and security issues that organizations are experiencing in cloud computing environments is especially problematic. Developers often employ infrastructure-as-code (IaC) tools to provision cloud infrastructure. Unfortunately, they typically lack security and compliance expertise, which then results in large numbers of misconfigurations.

    The Stacklet platform is designed to give DevOps teams a way to prevent compliance and security issues using a compliance-as-code framework that spans multiple cloud platforms rather than requiring DevOps teams to employ a different set of compliance tools for each cloud platform on which applications are deployed.

    It’s not clear yet how far left responsibility for compliance will shift. In theory, organizations could avoid penalties if compliance issues are addressed before an application is deployed in a production environment. However, the teams that manage compliance in larger enterprises today are even further removed from DevOps teams than their cybersecurity counterparts. It may be several years before the cultural divide between these teams is bridged. In the meantime, many DevOps teams are taking it upon themselves to manage compliance as code to prevent unexpected issues from arising at the last minute before deployment.

    Overall, the goal is to enable DevOps teams to enforce compliance policies without slowing down the rate at which applications are built and deployed. The hope is that the adoption of compliance-as-code and DevSecOps best practices will address that issue. In fact, as the pace at which applications are deployed continues to accelerate to support digital business transformation initiatives, the number of potential compliance issues steadily increases. More troubling still, the greater the number of compliance issues there are, the more likely it becomes that cybercriminals will find a vulnerability to exploit.

  • Reflections: A DevOps Christmas Carol

    Reflections: A DevOps Christmas Carol

    “Marley was dead, to begin with.” So begins my DevOps Christmas Carol. In this reflection, I am visited by the ghosts of DevOps past, present and future. I hope that, after hearing my story, you will have a better understanding of where DevOps is going based upon where it came from and where it is now.

    The Ghost of DevOps Past

    The ghost of DevOps past took me back to Las Vegas, 2012. I shared a bottle (or two) of wine with Gene Kim, Gene was talking about a manuscript for a book he was working on based on The Goal by Eliyahu Goldratt. It was a digital story of resource constraints and the way forward based on something called DevOps. I was fascinated by this new way of thinking about development and operations while musing about what a great thing that could be for security, which was my thing then. A whole new world opened up to me as I met and learned about the work of people like Patrick Dubois, John Willis, Jez Humble, Damon Edwards and more.

    I was taken to Boulder, Colorado where Foundry Group and Techstars were putting on a symposium to make sure their portfolio companies were smart about DevOps. The CTO of Rally software did a presentation on Agile and DevOps and, again, it was like looking at the IT world from a whole new vantage point. It was after speaking to some of my friends, Rajat Bhargava and Brad Feld, that the idea for what became DevOps.com was born.

    What a golden time that was. DevOps was an elusive thing. No manifesto, no official definition. Some people said it was mythical and not real. Others said it was just for startups born in the cloud. Still others said it was just for large enterprises. DevOps, it seemed, could be everywhere and nowhere, all at once.

    Looking back, it was an exhilarating time, with philosophical arguments vigorously debated. And over the weeks, months and years that followed, the idea of DevOps became a real thing, the benefits it provided revealed themselves and a set of best practices emerged. My partners at the DevOps Institute and I tried to capture these emerging best practices and build courseware and certifications around them. Oh, my—what a sh*tstorm that created. The idea of being certified in DevOps was scoffed at, derided, spit on and ridiculed. But that, too, eventually passed. Looking back at this part of my trip, I realized that while it all seemed idealistic and exciting and despite the ups and downs and bumpy road, we were always moving forward.

    The Ghost of DevOps Present

    Next, the ghost of DevOps present visited me. In this dream, DevOps had begun to blend into the woodwork. For the most part, it was an accepted way of developing and operating software. Many principles such as CI/CD, continuous testing, SRE and DevSecOps were mainstream. While not 100% fully adopted, the majority of organizations used some DevOps patterns in their business.

    It had become so mundane, in fact, that people began to ask, “Has DevOps hit the wall?” “Has DevOps passed its peak?” and “What’s next for DevOps?” While this may sound ominous, it is actually par for the course in the adoption cycles of new technologies. As certain as the Gartner hype cycle, technology that has settled into the stack seems to be the way of things. So as much as the ghost of DevOps present tried to frighten me, I was unafraid. Adoption was proceeding just as expected. It was firmly entrenched as part of digital transformation initiatives. Cloud-native and DevSecOps also were becoming more and more accepted.

    The Ghost of DevOps Future

    Next, I was visited by the ghost of DevOps future. She showed me a glimpse of what the future held. In this future version, SREs worked side-by-side with DevOps teams. There was a smooth handoff at the time of deployment ensuring that apps behaved the way they were intended. Automated feedback loops allowed developers to incorporate lessons learned into future versions. 

    Low-code/no-code solutions designed for developers allowed for even faster, automated deployments. AI-enabled applications let testing keep pace with development, more automation enabled even faster deployments. 

    AI also made observability more than just a spectator sport. Actionable intelligence that was wisely acted upon was the norm in this future. Of course, security was still an issue. There were even more regulations and compliance requirements. The bad guys were as notorious as ever. It seems even a DevOps future where security was everyone’s responsibility could not fully solve our security issues. But, overall, progress had been made.

    DevOps teams were deploying directly from Git onto cloud-native stacks that started with Kubernetes but didn’t end there. There were service meshes and APIs connecting everything. Serverless platforms were offered by most vendors. Overall, no one wanted to be locked into one cloud provider and picked the right cloud for each project. Indeed, DevOps in the future seemed on the verge of recognizing and achieving many of its aspirations.

    I awoke and felt good about everything that was happening with DevOps. In the words of Tiny Tim from that other Christmas carol, “God bless us, every one!”

  • 5 Ways Low-Code Accelerates Digital Transformation

    5 Ways Low-Code Accelerates Digital Transformation

    Organizations traditionally have struggled with build-versus-buy decisions when digitizing their internal operations and processes. While the build option offered the benefit of using internal teams or outsourcing to external vendors who could satisfy requirements, the downsides are a long wait, higher costs and the constant change and maintenance applications require. On the other hand, buying solutions off-the-shelf meant that the costs were lower but the businesses would have to change or adapt to already-crafted solutions; not all businesses could adhere to a one-size-fits-all solution. 

    This challenge often resulted in only the highest-priority and big-budget applications or tools seeing the light of day while others were put on the back burner—even if those back-burnered tools could have improved productivity and user experience.

    Enter low-code platforms. The adjacent skill phenomenon enables users with similar fundamental experience but in different niches—think web developers and designers—that, when provided with a drag-and-drop tool can supplement their experience to move up the value chain and become full-stack developers.

    In a similar way, low-code platforms enable backend engineers to use drag-and-drop tools to build UI and business logic quickly. This translates into full-stack skills and makes frontend engineers redundant for internal tooling. With low-code and no-code tools, backend engineers can create dashboards, CRUD apps, transactional systems, processes and workflows built on top of existing data sources like databases, connected via APIs, housed in third-party tools etc. These solutions can easily be created and deployed in a matter of hours instead of weeks or months or, worse, back-burnered and doomed to never see the light of day. 

    How Does Low-Code Accelerate Digital Transformation?

    Given that most businesses are struggling to find the right tech talent, they need to explore new approaches to meet the demands associated with digital transformation. Low-code helps by making coding less burdensome and reducing the time and resources spent in building digital solutions. Anyone can develop apps regardless of their technical expertise and, therefore, contribute to the acceleration of digital transformation. 

    Here’s a look at how low-code solutions are accelerating digital transformation.

    Accelerating Visual Development  

    Low-code platforms can reduce turnaround time for building new apps by 90%—from well over six months to under four weeks.

    Developers and non-developers alike can use drag-and-drop functionality to build frontend applications on the fly. A major capability low-code platforms provide is the ability to build functional prototypes of possible solutions and test them quickly. Low-code platforms help unlock innovation by giving low-code platforms to business users who know and understand operational challenges best. Business users can create functional prototypes and iterate toward fully functional applications.

    How? Visual drag-and-drop interfaces, ready connections to data sources and APIs, point-and-click workflow designers and baked-in security. By taking away much of the boilerplate, most low-code app development projects are delivered with little to no coding required in a short time. 

    Along with a catalog of pre-built components and pre-configured modules, component reusability is another advantage of using low-code tools. Using standard UI components such as menu bars, buttons, form sections, etc. allows a user to take advantage of pre-built UI components and merge them into a full-fledged application.

    Democratizing App Development

    Gartner found that the demand for business-related apps is five times higher than the available IT capacity.

    That means the talent gap is one of the biggest hurdles to digital transformation. By turning a large number of semi-technical employees into citizen developers, companies can empower teams to create high-quality digital solutions for everyday operations while still meeting IT security regulations and addressing cybersecurity concerns. Low-code offers an intuitive user interface to design applications, websites, workflows and automation recipes. Some of the more refined low-code platforms also support backend integrations; meaning users can connect their digital solution to multiple data sources and produce unified web portals. 

    So, in addition to increasing the development resources, citizen developers can also help to accelerate business value. While they create business apps, the more complicated digital issues can be managed by the IT department. 

    Easy Data Integration

    Customization is the best way to extract the maximum value from existing systems. 

    Tools built using low-code technology are highly customizable and scalable. Low-code platforms enable the rapid creation of purpose-specific applications, which, via API connectors or building middle layers, can be “stitched” together with legacy applications to create end-to-end products. With easy-to-use API and database integrations, this allows teams to integrate with any pre-existing enterprise software such as ERP, CRM, custom applications and databases and extract the richness from their core legacy investments. 

    Reduced Costs and Scalability

    Many enterprises have project backlogs that cost them billions of dollars in opportunities. Because they can’t find the right talent or software to address business opportunities fast enough or give them priority over other tasks. Low-code can help reduce backlogs by helping your development team get more done in less time.

    Low-code development turns application elements like pre-built UI components, integrations and custom logic into visual building blocks that are easy to copy and repeat. Ready connections to multiple data sources allow users to easily connect to data from different business functions and scale the application. 

    A low-code approach simplifies the work required to scale and maintain apps across the entire enterprise or for millions of customers. The developer can build something once and implement it everywhere in minutes. Easy cloud deployment makes it easy to extend the application from one geographic location to another.

    Eases Application Life Cycle Management 

    The main aim is to produce flexible, cost-effective and rapid applications that are adaptive to enhancements and less complex in terms of maintenance. Low-code development accelerates application delivery by enabling users to deploy applications in just a few clicks, without relying on DevOps or engineering teams. 

    Depending on the platform, all the stages of the application life cycle—development, deployment, monitoring, maintenance, updates—can be performed from a single point in real-time, ensuring security, compliance and version control.

    The maintenance phase of software is vital to be able to quickly change what already has been developed to guarantee that the app continues to serve the purpose the business requires. The essence of low-code is that, as the name suggests, there is less code; therefore, there is little code to maintain.  

    The Future of Low-Code and Digital Transformation 

    All kinds of organizations across all industries are seeking new ways to meet challenges and increase business performance as a result of digital transformation. Introducing low-code/no-code enables businesses to be bolder and more experimental when executing on their ideas. This is digital innovation in action.

    Businesses are already leveraging low-code to get ahead of their competitors by increasing business agility and improving efficiency. This technology is giving IT teams the potential to also get rid of old silos between business departments. 

    Low-code has been helping enterprises overcome the lack of access to relevant resources to meet their business needs. By speeding time-to-market for digital products, low-code helps businesses respond to market dynamics faster while being more efficient. 

    Every organization should take advantage of these opportunities and adopt a low-code platform for accelerating productivity and achieving faster results, apps and tools. In the words of Chris Wanstrath, CEO of GitHub, “The future of coding is no coding at all.”

  • How Developers Can Handle the FinServ Data Deluge

    How Developers Can Handle the FinServ Data Deluge

    A decade ago, if you were to ask developers what the biggest challenges in commercial banking were, they would likely cite the difficulty of accessing and collating high-quality data on the day-to-day operations of banking institutions. Today, that’s completely changed.

    Or it has to some extent, at least. Developers working in the banking industry certainly have access to more data than ever before. But this has created challenges of its own. With so much data being collected, stored and at least partially processed, some developers have started to talk of a “data deluge”—an unstoppable torrent that overwhelms the developer’s ability to process and use it.

    In this article, we’ll try and make sense of this. We’ll also explore what it is being used for and what this means for the future of the banking industry.

    Promises and Challenges

    Before we get too deeply into the specifics, however, let’s take a moment to note that the data deluge is not entirely new and that it will be with us for quite some time to come.

    In fact, most guides to technology in the banking sector note that many of our current issues are caused by the sheer amount of data being collected. It has become acutely apparent that our data harvesting capabilities have grown far more rapidly than our ability to ensure accuracy or to label it in accordance with legally-mandated compliance frameworks.

    And, of course, this is only going to get worse. No one knows yet how the global COVID-19 pandemic and ensuing economic downturn will affect the global payments market, but it was previously predicted to reach $2 trillion by the end of 2025, with a compound annual growth rate of 7.83%. Even realizing a portion of that growth will create real challenges for developers in the banking sector.

    Using the Data Deluge

    With all that said, however, let’s also recognize that this is a ‘good problem.’ It’s not necessarily a bad thing that we have access to so much data—the issue is making sure that it’s accurate, safe and useful.

    And when it comes to doing that, three opportunities are already apparent. Here they are.

    1. Increased Velocity

    Many of the new approaches to leveraging data in the banking sector are focused on increasing speed. Indeed, the ability to access real-time intelligence in banking operations was one of the original promises of the big data revolution, albeit one that has taken some years to come to fruition.

    There are several reasons for that, but one of the most important is the fact that banks have lagged when it comes to updating their hardware and software to correlate with the amount of information they are collecting. Most banks now undertake significant levels of quantitative analysis on business and customer data, for instance, but few do so in real-time.

    Instead, many banking systems are still run on monthly data-processing schedules, meaning that it can take even the most technologically advanced bank 30 days to spot consumer or business trends. Implementing new technologies such as Apache Spark is one potential solution to this problem. Like Hadoop, it’s an open source big data analytics engine, but it’s faster, more scalable and easier to use.

    2. More Reliable Governance

    Another challenge when it comes to managing the deluge is that of governance. With so much data flowing in, it can be a challenge for developers and operations staff alike to keep track of its source and how it should be managed within data compliance frameworks.

    This is one reason, as we’ve long argued, that banking should consider DevOps. By uniting developers and operations staff, both can come to a deeper understanding of data compliance and how this must be integrated into every aspect of the contemporary banking industry.

    This is one area, however, in which more data is not necessarily a bad idea. Rather than pausing data harvesting because of concerns that it will create compliance issues, developers should aim to build systems that can carefully and reliably label this data throughout the custody chain.

    3. Focus on the Customer

    Finally, developers shouldn’t lose sight of the ultimate aim of collecting data—improving the customer experience. Data can be used to do this in two primary ways.

    The first is to put data to work in your customer-facing systems. This is the approach recently pioneered by Western Union, which offers an omnichannel approach that tailors and personalizes customer experiences by processing more than 29 transactions a second and integrating all that data into a single platform for statistical modeling and predictive analysis.

    Secondly, data can be used to inform strategic decisions. Just as consumers are now more savvy about the way that their data is used, leadership needs to understand that this type of data-based decision-making is the future of the industry.

    In other words, banks must be able to move faster to transform their data into intelligent insights and then put those insights into action to improve customer service, connect customers to information and products when and where it’s needed most and protect sensitive data and customer accounts from threats.

    The Bottom Line

    The data deluge creates challenges for developers and leaders alike. These challenges are only going to grow as our ability to harvest consumer and industry data continues to expand. If we are going to realize the promises of technology-driven banking, we need to improve the way in which data is managed and processed and ultimately improve our ability to extract meaningful insights from that data.

    And just as this challenge is not new, neither is the outcome—a better banking experience for the customer.

    If you want to learn more about financial services and FinTech development, operations, architecture and leadership through expert-led talks, panel discussions and keynotes, check out FinCon DX—now available on demand!

  • Sentry Acquires Specto to Add Analytics Tool for Observability

    Sentry Acquires Specto to Add Analytics Tool for Observability

    Sentry this week announced it has acquired Specto, a provider of a set of tools for analyzing the performance of mobile applications.

    As the number of mobile applications being deployed continues to expand, developers are being asked to manage them as part of a general shift left that requires them to take on more accountability for how well their applications run in a production environment.

    Sentry CEO Milin Desai said today the Specto tools are focused on making it easier for developers to determine how mobile applications are running, but that the plan is to expand that analytics capability to a wider range of applications.

    As the responsibility for applications continues to shift left toward developers, the need for observability and monitoring tools that developers can easily use is becoming more acute. Sentry already provides a JavaScript software development kit that enables developers to insert a small amount of code in their application to track, for example, how many times an application failed. The Specto tools will take those observability capabilities to a deeper level by enabling developers to analyze a wider range of metrics collected, said Desai.

    Of course, DevOps teams are already collecting metrics, as well. Sentry has worked with partners such as GitLab and GitHub to provide a plug-in that makes it possible for DevOps teams to see the same metrics that developers are now using to manage applications. The goal is to make it easier for developers and IT operations teams to collaborate around a common set of metrics, said Desai.

    The rate at which responsibility for the management of applications is being shifted left, of course, varies widely. Some organizations continue to prefer to have developers mainly focus on writing code. However, Desai said Sentry is encountering more instances where site reliability engineers (SREs) are providing Sentry tools to developers as part of an effort to provide them with more insight into how their applications are running in a production environment.

    Historically, IT operations teams have relied on application performance management (APM) platforms to manage IT operations. Those platforms are now evolving into observability platforms that promise to provide more context by correlating events as they occur across both applications and IT infrastructure platforms. That approach, however, typically requires developers to insert agent software into their applications. Once inserted, that agent software needs to be maintained and updated within the context of a larger DevOps workflow.

    The Sentry approach provides developers with a tool for collecting data from an application that, after being embedded in the application, consumes just tens of kilobytes of memory. That approach eliminates the need to rely on much larger agent software to achieve observability.

    Regardless of how developers go about instrumenting their applications, the overall state of observability clearly needs to improve as application environments become more complex. The issue now is determining how best to achieve that goal in a way that benefits both developers and DevOps teams alike.

  • AWS Outage Exposes Weaknesses of DevOps Resilience

    AWS Outage Exposes Weaknesses of DevOps Resilience

    The December 7, 2021 Amazon Web Services (AWS) outage severely disrupted services from a wide range of businesses for more than five hours and highlighted just how reliant businesses have become on internet-delivered services. The outage mostly impacted web services in the eastern U.S., yet the implications are universal: It’s a reminder that many businesses blindly ignored the old axiom about putting all your eggs in one basket and instead are relying on a provider with a single point of failure.

    Services ranging from airline booking systems to streaming video to e-commerce were disrupted during the outage, causing millions of dollars in lost revenue and countless hours in productivity. One of the more interesting aspects of the outage is the impact it had on services from collaboration vendors such as Slack, Trello, Asana and Smartsheet—tools that many development and DevOps teams have come to rely on.

    Furthermore, core AWS services, such as the company’s Elastic Compute and DynamoDB cloud tools were also impacted, disrupting many third-party services and severely hampering business processes that use those services. While the obvious victims of the outage are well known, like Amazon’s own e-commerce operation, there is a troubling undercurrent: The disruption to DevOps frameworks and those using them.

    AWS has been rather tight-lipped about the root cause of the outage thus far; however, there are still many lessons to be learned for the DevOps community and questions that must be asked such as “Can the DevOps process survive during IaaS/SaaS disruptions?” and “Can multi-cloud failover solutions be baked into the applications DevOps builds?”

    There are no simple answers to those questions, but the outage highlights the need to understand the underlying architecture and framework of a deployed DevOps system. Take, for example, how many developers in the DevOps community have embraced SaaS tools to accelerate the development process and to feed CI/CD pipelines. SaaS applications such as code scanners, pipeline orchestration and even IDEs have become common in the world of DevOps. But has anyone bothered to ask what happens if a single one of those tools fails?

    What’s more, the reliance on SaaS tools in the development process has led to the creation of potential liabilities in the applications created by DevOps developers. DevOps applications have come to rely on APIs, are often driven by microservices and are frequently deployed into containers that run on SaaS. If any of those elements become non-functional, numerous applications could fail, ultimately putting the onus on developers to explain why they are creating applications with a single point of failure.

    Moving forward, the DevOps community needs to take a serious look at the components of their frameworks and determine if there are any single points of failure—including their IaaS/SaaS providers. While it may be impossible to remediate every single one, there is a lesson to be learned about how fragile the development process can become if no one bothers to build an inventory of the tools used and take into account how a failure of any one of those tools could impact workflow. There are numerous examples of how an external failure of a single component impacted the functionality of an application, while the discovery process of the root cause has taken days or even weeks. This can be mostly attributed to not only a lack of knowledge, but a lack of visibility into the components used.

    Those lessons can be extended to the development process itself, where the best practice of rooting out single points of failure can be extended to the applications themselves. Leveraging that intelligence starts with understanding the concept of a software bill of materials (SBoM), a piece of supporting documentation that is becoming increasingly important to the purveyors of applications. A properly-defined SBoM reveals all of the components (libraries, APIs, etc.) that are baked into an application and can be used as a map to define where weaknesses may lie.

    For the DevOps community, the recent AWS outage has become a clarion call to look inward and discover how the applications they are building may be part of the problem. With continuity and resiliency becoming major topics in the IT and business realm, it’s about time that DevOps practitioners start to look at how they can support both of those business-critical needs. The days of finger-pointing to shift blame must come to an end, and if businesses that rely on software want to grow, someone needs to take responsibility for providing answers when outages occur and learn from those outages to create applications that are more resilient.

  • Vercel Acquires Turborepo to Gain Build System

    Vercel Acquires Turborepo to Gain Build System

    Vercel today announced it has acquired Turborepo, a provider of a build system for JavaScript and TypeScript applications that provides developers with access to an easy-to-use monorepository for their code.

    In the wake of that acquisition, the command line interface (CLI) for accessing Turborepo will now be available under an open source license.

    Jared Palmer, creator of Turborepo and other popular open source projects including Formik and TSDX, will continue working on accelerating Turborepo’s capabilities as the new leader of a build performance team at Vercel.

    The goal is to move existing users of the Turborepo cloud service to a Vercel platform for building applications using the Next.js framework, which makes it possible to build web applications based on the React library for creating user interfaces that enable both static site generation (SSG) and server-side rendering (SSR).

    Palmer said monrepositories such as Turborepo not only make it easier for developers to manage builds but also reduce the amount of time required to process those builds using a continuous integration/continuous delivery (CI/CD) platform.

    Rival build systems are also much more complex to configure and manage, which Palmer said is a primary reason many developers have not yet set up their own mononrepositories.

    As the number of applications that organizations want to build and deploy in the digital business transformation era increases, the focus on developer productivity is intensifying. Rather than having to maintain a complex build system, Turborepo is designed to be simple to configure. As a result, more developers can reduce build times by as much as 50%, noted Palmer.

    In effect, front-end developers are able to more easily become full-stack developers by combining that build system with the Next.js framework, he added.

    DevOps teams will need to adjust to applications capable of providing richer application experiences without relying as much on backend infrastructure. That shift has implications for everything from the amount of network bandwidth consumed to the performance of web applications. The Vercel platform employs caching, routing and a React framework to optimize application performance in a way that reduces the dependency on backend infrastructure to optimize application performance.

    As web application development continues to evolve, the overall rate at which they web apps are built should increase significantly. Naturally, DevOps teams will need to consider the implications of having more applications move through DevOps pipelines and the need to continuously update those after they are deployed.

    It’s not clear whether or how much DevOps teams will nudge developers toward frameworks such as Next.js to develop web applications that might not tax backend infrastructure as much as previous generations of applications. In effect, developers can take advantage of frameworks that enable them to treat the underlying IT infrastructure as if it were serverless whenever possible with tools that have a familiar JavaScript construct. Vercel claimed there are already more than 30,000 sites running Next.js in production at organizations like Airbnb, Hulu, Nike, Ticketmaster and Uber.

    One way or another, it’s clear that the way web applications are being built is fundamentally changing. The only issue now is determining to what degree the rest of the IT organization is prepared to absorb that level of change.

  • AWS Outage Outrage | Rusty Linux | ARM Latest

    AWS Outage Outrage | Rusty Linux | ARM Latest

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Amazon Web Services falls on its face, Linux’s move to Rust takes the next step, and the FTC stabs another fatal wound in the horrible Arm/Nvidia deal.

    AWS us-east-1 Breaks the Internet

    First up this week: Amazon Web Services’ outage on Tuesday sent scads of DevOps teams scrambling. But what was the cause?

    Analysis: DNS DDoS?

    While we still don’t officially know, there is some chatter to speculate on. Could it be that AWS’s DNS infrastructure is vulnerable to DNS reflection attacks?

    Hello. It’s Dave Lee: From angry Adele fans to broken robot vacuums

    It started early on Tuesday morning. Robot vacuums ceased sucking, Wi-Fi cameras stopped watching and eager Tinder daters were left unable to “swipe right.”
    …
    Within Amazon itself … the unthinkable occurred: grounded delivery drivers were unable to load packages and deliver to customers’ doorsteps, just as the peak Christmas season begins to step up. … Drivers at multiple facilities across the country were sent home … some dreading whatever workload may await.
    …
    An outage at Amazon Web Services … had rippled through the online economy, crippling services used by millions of people. … An “impairment of several network devices” in … US-EAST-1 was the “root cause” of the disruption, Amazon said.


    I was wondering what DevOps’ers learned? Enter Max Rozen:

    AWS took approximately an hour to update their status page to indicate anything was happening. … While our infrastructure is hosted across 20 AWS regions, a single point of failure was hosted in us-east-1.
    …
    What we learned: … I learned the saying, “Friends don’t let friends deploy in us-east-1.” As a result, we’ll be moving some things over to us-east-2 to start with. Secondly, we’ll be adding redundancy and the ability to failover to another AWS region.


    Getting inside the business, here are Eugene Kim and Katherine Long, to go over everything:

    Even inside AWS … information on the outage remained sketchy [and] rumors spread among staff. One AWS employee speculated that the outage was caused by an “orchestrated DNS attack,” while another employee downplayed those concerns.
    …
    According to a screenshot of an internal AWS communique … ”firewalls are being overwhelmed.” … A separate internal note said … the network issue “specifically impacted” Amazon’s internal DNS servers.

    Linux Officially Gets Rust Code

    The Rust language has taken the next step toward being part of Linux kernel development. Some “drivers and other non-core kernel programs” written in Rust can now be PR’ed. But there’s still no plan to go further.

    Analysis: Still needs lubrication

    Rust is much better than C for writing memory-safe code, and coding provable implementations. However, bootstrapping the toolchain is still stupidly hard.

    Steven J. Vaughan-Nichols: Linux is getting more Rust in it by the day

    It wasn’t that long ago that the very idea that another language besides C would be used in the Linux kernel would have been laughed at. [But] this has been coming for several years now. … Why? Because it’s much safer than C, especially at handling memory errors.
    …
    The next “patch series [adds] support for Rust as a second language to the Linux kernel.” … While he’s encouraging a slow but steady approach to introducing Rust into Linux, [Linus Torvalds] has also said that using Rust interfaces for drivers and other non-core kernel programs makes sense. [But] no one’s going to rewrite the kernel’s 25 million lines of C in Rust.
    …
    The Rust code proposed for the kernel now relies on the stable Rust compiler rather than the beta compilers. … As Linux kernel and lead Rust on Linux, developer Miguel Ojeda, put it, “By upgrading the compiler, we have been able to take off the list a few unstable features we were using.”


    How is it “safer than C”? ssokolow shares this fascinating insight:

    Rust tries to encourage that through good API design which allows it to be proven at compile time that the invariants will be upheld, thus avoiding the need to choose between safety and performance. My favourite example … is “the typestate pattern” which lets you teach the Rust compiler to prove correct traversal of any state machine.
    …
    A more mundane example would be the iterator APIs: No need for bounds checking if the iterator looks up the length once at the beginning and the APIs prevent you from wandering out of each entry it hands you. … Rust programs tend to run faster than their C and C++ counterparts because the developers feel comfortable introducing and maintaining more aggressive optimizations.


    “And then a miracle occurs,” quips @dave_universetf:

    I’m intrigued [but] I can’t help but feel sorry for the people doing bootstrapping work. C is hard enough to bootstrap, but Rust is a whole new level of pain.
    …
    Rust is literally not source bootstrappable. [The compiler] that works right now is Rust 1.39. So then you have to compile 18 more Rust compilers to get up to the current version.

    Nvidia’s ARM Woes Continue

    As I’ve said before, this deal really shouldn’t go through. Ownership of the ARM ISA and the core designs would be a huge strategic stick to beat Nvidia’s competition with. ARM chips are an increasing fixture in the datacenter—especially those that value “performance per Watt.”

    Analysis: Stick a fork in it

    Nvidia’s attempt to buy Arm from SoftBank is suffering death by a thousand cuts. And the latest wound comes from the FTC’s Higonokami knife.

    Paul Thurrott: FTC Sues to Block Sale of Arm to Nvidia

    The U.S. Federal Trade Commission … sued to block Nvidia’s $40 billion acquisition of … Arm, citing competitive concerns. … Nvidia announced its intention to purchase Arm from Softbank for about $40 billion, over one year ago, in September 2020. But the deal fell under immediate criticism from the major industry players that rely on Arm’s … designs, and the UK government announced … it would “intervene” for national security reasons.
    …
    Now, it may not happen at all. “We will continue to work to demonstrate that this transaction will benefit the industry and promote competition,” Nvidia said.


    Explain like I’m 5? Here’s swillden:

    ARM has a non-trivial and increasing share in the data center. … ARM is much, much bigger than phones … Arm is an important competitor to Intel and AMD. … Arm licensing IP to Qualcom, nVidia, Mediatek, Unisoc, Samsung, Apple, Google, etc., has been great for many areas of technology.
    …
    Arm acting as a common … designer for a bunch of different chip vendors has been extremely good for … progress in CPU/SoC design. … It would be really unfortunate if a lot of the industry were to shift back to x86, eliminating all of the competition on hardware features that we get from the many ARM chipmakers.


    But what of SoftBank? Ian King runs the numbers:

    Wall Street analysts are all but calling the deal dead. … According to Citibank analysts, the chances of the Nvidia purchase closing are now just 5%.
    …
    The company faces the prospect of losing a jackpot of roughly $74 billion. … Other suitors are unlikely to match such an offer. … So SoftBank’s best alternative may well be an initial public offering for the Arm business—but that is likely to value the company at … $19.8 billion—only about 27% the value of the … Nvidia deal.

    The Moral of the Story: It’s no secret that the both of us are running out of time


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk. (It’s so typical of me to talk about myself—I’m sorry.)

    Image: Ləman Şirinzadə (via Unsplash)

  • Literary Value

    Literary Value

  • Digital Business Transformation Driving More API Adoption

    Digital Business Transformation Driving More API Adoption

    A global annual survey of 2,200 developers published today by RapidAPI, a provider of an application programming interface (API) hub, finds digital business transformation initiatives have led to an increase in reliance on external-facing APIs.

    According to the survey results, nearly three-quarters of developers (74%) are using APIs for internal applications. However, nearly half (49%) said they are working on third-party APIs, with 44% working on partner-facing APIs. That’s up from 35% a year ago.

    RapidAPI CEO Iddo Gino said it’s clear APIs are a key enabling technology for driving digital business transformation initiatives.

    More than three-quarters of developers (75%) indicated that participating in the API economy is a top priority for their organization now or in the near future, according to the survey results. Companies are realizing the opportunity for new revenue streams, with growth in API monetization strategies increasing to 41% from 35% in 2020.

    In addition, more than two-thirds of developers (68%) said they expect to increase API use in 2022, with 61% relying on APIs more in 2021 than in 2020.

    However, well over half (56%) noted that a shortage of developer talent is a top concern, followed by lack of internal prioritization around digital transformation efforts (34%), lack of API development resources and tools (32%) and lack of alignment with other departments (29%). A full 90% also noted that security and data privacy is a key issue to consider when employing APIs.

    The results also show the use of REST and SOAP APIs in production environments fell 3.7% and 1.4%, respectively, in 2021. That drop reflects the rise of alternative API technologies such as GraphQL and Async APIs, said Gino, However, he noted it’s unlikely any new class of APIs is likely to supplant legacy APIs anytime soon; instead, most organizations will be employing a wide range of APIs for many years to come.

    The survey results reveal that JavaScript is the most used (71.6%) and preferred (51.9%) programming language for building APIs. TypeScript is also gaining traction in terms of usage (20%) and being preferred (12%).

    The most troubling aspect of the survey, however, may be the fact that well over half of respondents (56%) said they are open to switching jobs. The top five reasons developers said they might switch jobs are higher compensation or improved benefits (60%), interest in a specific product or technology at a different company (54%), desire for a more flexible working environment (38%), interest in a specific company or market (25%) and an opportunity to work with former teammates or friends (17%).

    It’s not clear to what degree the so-called Great Resignation phenomenon might be impacting DevOps teams in general. However, it’s apparent no class of jobs is immune from a general sense of restlessness that pervades the market as the global economy continues to recover from the COVID-19 pandemic. The challenge and the opportunity for DevOps leaders is to encourage the best talent available to join and then remain with their organization versus pursuing a job somewhere else that, at least from afar, appears to have greener pastures.