devopsy.kinsta.cloud

Tag: application development

  • 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.

  • Postman Survey Shows Focus on Building and Deploying APIs

    Postman Survey Shows Focus on Building and Deploying APIs

    A survey of more than 28,000 developers and application programming interface (API) professionals published today by Postman found nearly half of respondents (49%) are now spending the majority of their time developing APIs. More than a quarter (28%) now spend 20 or more hours per week working with APIs.

    Kin Lane, chief evangelist for Postman, a provider of a platform for building APIs, said that shift reflects an increase in software development and integration activity that began at the start of the COVID-19 pandemic. Almost two-thirds of respondents (63%) said the pandemic somewhat or significantly affected their work, with almost half of those respondents noting that changes made with their organization were enabled and supported by APIs.

    Additionally, a full 94% of respondents said the investment of time and resources into APIs will increase or stay the same for the next 12 months. The biggest obstacle to creating APIs is lack of time (45%) while the biggest obstacle to consuming an API is lack of documentation (55%). In terms of API goals, the survey found that quality (80%), agility (66%) and reliability (65%) are the top three goals among survey respondents.

    However, the survey also noted only a third of respondents said they could build and deploy an API in anywhere from a single day to a week, with most requiring one week to a month. About one-third also said they deploy APIs to production between once per week and once per month. More than 80% of respondents noted that less than 25% of their changes fail while a similar percentage said they can recover in less than a day with a third reporting they fully recover in less than an hour.

    The Postman survey also found that more than three-quarters of respondents (76%) have less than five years of experience with API development. Only half of respondents indicated that they agree or strongly agree that the leadership of their API team has a clear sense of where their API practice should be in five years. However, microservices (58%) and Kubernetes (50%), containers (46%), serverless architecture (44%) and GraphQL (35%) were ranked among the technologies that respondents were most excited about heading into 2022.

    On the plus side, more than 60% of respondents felt their API leadership and governance teams demonstrated a “willingness to change” as well as duly considering “the interests and opinions of employees.” When it comes to regularly providing feedback and process, more than half of leadership and governance teams (53%) scored well.

    The top two ways API teams collaborate is via a dedicated collaboration platform (50%) or by publishing API artifacts to repositories such as GitLab, GitHub and Bitbucket (45%), according to the Postman survey. The most widely used DevOps tools are Jenkins (37%), Azure DevOps (26%), GitHub Actions (25%), AWS DevOps (23%) and GitLab Pipelines (22%).

    In terms of deploying APIs, continuous integration/continuous delivery (CI/CD) platforms are the most widely employed (57%), followed by deploying APIs in the cloud (38%), frameworks (34%) and custom-built deployment methods (27%).

    Just over 70% of respondents ranked security and performance as the top factors considered when integrating with an API. When producing an API, however, the top factors are integration with internal systems, integration with external systems, adding functionality to an internal system and enhancing functionality for an end customer. Similarly, when consuming an API the top factors are integration with external systems, adding functionality for end customers, adding functionality to internal systems and integration between internal systems.

    In general, Lane noted that, as more APIs are developed and deployed to drive various digital business transformation initiatives, organizations will need to pay more attention to API discovery and management. There’s a tendency for different teams within organizations to not only create redundant APIs but also forget about so-called zombie APIs that are no longer supported but can still be exploited by cybercriminals.

    Overall, Lane said the survey makes it clear more organizations are pursuing an API-first approach to digital transformation. The challenge now is managing all the APIs that can quickly become too much of a good thing.

  • Progress Expands Chef Automation Portfolio

    Progress Expands Chef Automation Portfolio

    In advance of its ChefCon 2021 conference, Progress today unveiled a series of enhancements to its Progress Chef automation platform that includes managed services and a software-as-a-service (SaaS) edition of its offerings as well as tighter integration with cloud services and other third-party tools.

    Sudhir Reddy, vice president of engineering for the Chef business at Progress, said the SaaS platform, now available in beta, combined with the managed services provided by Progress will make the automation platform much more accessible to a wider range of organizations.

    Progress is now also extending the reach of its Chef Compliance Automation for Cloud Resources offering across Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP) to include Chef premium content that aligns with best practices for each cloud environment in addition to providing integration with Azure Policy, a suite of tools from Microsoft that compares resources to a set of business rules that define how cloud infrastructure should be employed.

    Chef

    Finally, Progress has enhanced Chef Enterprise Automation Stack to provide tighter integration between compliance and infrastructure automation along with adding infrastructure operations dashboard, support for Windows patch management, integration with third-party secrets management tools, and improvements to Chef Workstation and Chef Test Kitchen to simplify testing within application development processes.

    With the release of a SaaS platform and the availability of managed services, Chef is joining a long list of IT vendors that are removing responsibility for deploying and securing their platforms from internal IT operations teams. It’s clear more organizations now want to spend more time on building and deploying software than managing the platforms that automate those tasks on their behalf, said Reddy.

    It’s not clear how many IT teams that have already deployed a platform might shift over to a SaaS platform or rely on an IT vendor to manage that platform on their behalf. However, in the wake of the COVID-19 pandemic, many IT teams continue to work from home to help combat the spread of the virus. Many of those organizations have either shifted platforms to the cloud themselves, adopted SaaS platforms or outsourced the management of IT platforms altogether. There are also many small organizations that simply don’t have the internal expertise and resources required to stand up an IT automation platform on their own.

    That approach also makes it simpler to converge security, compliance and IT operations management within the context of a larger DevSecOps workflow, noted Reddy.

    The great paradox of IT automation has always been the level of expertise required to achieve it. Organizations that lack the expertise required to create automated playbooks, for example, don’t derive much value from an IT automation platform. It’s only been larger companies that have mostly derived the most benefit from investments in IT automation. However, as IT automation becomes more accessible via SaaS platforms and managed services, the level of expertise required to benefit from it naturally drops. In fact, with the advent of artificial intelligence (AI) for IT operations (AIOps), many manual IT tasks are increasingly being automated.

    It’s too early to say whether the IT industry as a whole is on the cusp of the next wave of automation, but the raw ingredients that make up the primordial soup needed to achieve that goal is, at this point, only awaiting a catalyst.

  • Low-Code is Table Stakes for Enterprises

    Low-Code is Table Stakes for Enterprises

    Enterprises across all industries are facing mounting pressure to deliver business value with speed and agility. In the digital age, companies that can’t keep pace often fall to the wayside, especially in light of increasing customer expectations and dynamic regulatory requirements.

    Speed has become table stakes. And business leaders have risen to the challenge across the board—focusing on efficiency and streamlined operations. However, despite enabling speed, many organizations still struggle to deliver value and continuously improve performance using technology.

    Traditional software development methods can no longer keep up with the demands of modern users. And so, to achieve speed and generate significant value, business leaders must leverage customized software with low-code capabilities, thereby empowering professional IT developers to develop and deploy business applications rapidly and seamlessly.

    Speed is Table Stakes, But So is Low-Code

    Low-code application development is certainly not a new phenomenon—in fact, the term low-code was originally coined in 2014. However, since its advent, an amalgamation of digital disruptions, hyperautomation and new technologies has led to an exponentially rising demand for low-code tools.

    According to Forrester, “Low-code development platforms are emerging as a key strategy to accelerate app delivery to support digital business transformation. And they have the potential to make software development as much as 10 times faster than traditional methods.”

    So, not only is low-code an absolute imperative in today’s business environment, it is the key to unlocking speed and agility in your operations.

    Fabrizio Biscotti, research vice president at Gartner, further states that, “Globally, most large organizations will have adopted multiple low-code tools in some form by year-end 2021. In the longer term, as companies embrace the tenets of a composable enterprise, they will turn to low-code technologies that support application innovation and integration.”

    What Does Low-Code Mean?

    When you Google “low-code” you’ll find a number of different definitions. Low-code means different things to different people, depending on their industry, their business needs and their experience with IT.

    Perhaps the most common interpretation of “low-code” refers to “no-code” development, wherein citizen developers are enabled with declarative, drag-and-drop tools to create applications without having to depend on IT.

    This type of low-code works well in cases where users are attempting to streamline simple workflows and automate standardized use cases. However, when business needs become more complex, the “no-code” approach can fall short.

    A low-code platform, in the truest sense, offers a broader and deeper set of capabilities, enabling professional IT developers to use a modeling-driven environment to rapidly develop and deploy mission-critical applications and address complex, content-driven business needs.

    Generating ROI From a Low-Code Platform

    The right low code platform enables far more than just speedy app development. By investing in one comprehensive low code platform, you can:

    • Simplify your complex, content-driven business needs
    • Enable mobile app development
    • Develop customer-facing and customer support applications
    • Streamline internal workflows
    • Create transaction-oriented standalone applications
    • Develop content-driven workflow applications
    • Modernize legacy systems
    • Reinforce backend systems to handle larger volumes of data and transactions
    • Build portals for internal and external users
    • Deliver an enhanced customer journey across multiple touchpoints
    • Deploy your applications in a cloud-based or hybrid environment
    • Scale your applications with agility

    Low Code is Here to Stay

    Gartner predicts that “Low-code application building would gather more than 65% of all app development functions by the year 2024 and with about 66% of big companies using a minimum of four low-code platforms.”

    So, not only is low code a business imperative today, it is only increasing in utility and ubiquity as we move into the future.
    For enterprises striving to stay on the cutting edge, the right low-code platform is an investment that will keep on generating significant returns. From enabling speedy app development to providing the agility and scalability to keep up with dynamic business needs and customer expectations, low-code is the key to continuous innovation and ongoing success.

  • The Move Away from Monolithic Application Development

    The Move Away from Monolithic Application Development

    Shifting from monolithic application development

    Businesses need agility to deliver better services, meet changing requirements, and seize new opportunities as they arise. At the heart of many efforts are applications based on modern development strategies and techniques. Specifically, many businesses are moving away from monolithic applications of the past that are hard to modify and take a long time to bring to market.

    Why the shift and why now? Over 80% of organizations expect to compete mainly based on customer experience (CX). As a result, businesses in the most competitive markets like retail, banking, insurance, financial services, and travel/hospitality cannot afford to wait months or years to release new services, applications, or features.

    The bottom line is that software development teams are under pressure to deliver more of everything (new applications, enhanced features, more access options) in shorter time frames. A widely cited past industry study put the issues into perspective. Leading companies routinely perform multiple deployments daily. By comparison, low performers reported deploying only once a month at best. (At the extreme end of the spectrum, companies like Amazon and Google do deployments thousands of times a day.)

    Monolithic application development does not work in this fast-paced environment. A simple change in an existing application, such as incorporating a new dataset, adding new features in a front-end app, or using a different analytics method, requires that the entire application be revised, retested, and redeployed. That all takes time. Lots of time.

    A better approach is to use modern applications development methodologies. In particular, there is a shift underway to using cloud-native architectures based on loosely connected microservices and elements.

    A cloud-native approach is particularly well-suited for modern applications for several reasons. For example, a cloud-native approach helps organizations address the customer experience drivers that require constant updates and new services. Each component of a cloud-native application can be deployed and maintained as a self-contained microservice. If any element of a broad application needs to be updated or changed, only that element needs to be touched. The rest of the conglomerate application remains the same.

    z/OS plays well with cloud-native

    Many industries under the greatest pressure to speed development and deliver ever-more customized, personalized customer experiences use z/OS systems. As noted, these are retail, banking, insurance, financial services, and travel/hospitality. Government also can be added to the list. It is a large user of z/OS systems and is constantly trying to improve access to its services via new or improved web, mobile, chat, social, and phone applications.

    There are two ways to enhance and develop applications for these systems that use modern development methods. One is to make data, applications, and services that run on z/OS systems available as APIs and as microservices to be used by larger cloud-native applications.

    The other method that is gaining more favor is to provide the modern development tools for the z/OS systems themselves. Specifically, modern application development approaches that move away from monolithic architectures need certain essential elements. Many rely on open-source development techniques, workflow automation, and continuous integration and continuous delivery (CI/CD) tools.

    Bringing such commonly used tools to the z/OS environment helps businesses speed the development of new applications to meet changing demands of their customers. It allows a business to leverage the data and applications on its z/OS systems and create innovative new applications.

    In an age when it is getting harder to find developers with expertise in native z/OS programming, bringing familiar DevOps tools to the z/OS environment offers several benefits. Those who have the native z/OS skills can focus on core applications and leave the tasks like supporting a new front end or enhancing a web interface to others. After all, there are many more developers available with modern development skills.

    Bringing the DevOps tools into the z/OS environment also lets businesses retain all the pluses of those systems. Namely, businesses are assured that the same reliability, superior performance, tightly controlled security, and massive scalability are retained and can be leveraged with integrated with a broader cloud-native application.

     

     

  • Engineering Applications for DevOps (Part 6)

    Engineering Applications for DevOps (Part 6)

    This blog series explains how to engineer applications for DevOps.

    Topics covered in this blog series include:

    • Factors used to decide whether an application is a good candidate for DevOps.
    • Practices to engineer designs for DevOps.
    • DevOps applied to enterprise apps and software services.
    • DevOps applied to COTS systems.
    • DevOps applied to manufactured (embedded) systems software.
    • Five levels of application maturity.

    This blog covers five levels of application maturity. You can read part one here, part two here, part three here, part four here and part five here.

    Five Levels of Application Maturity

    Why is it that younger applications are more mature than older applications? DevOps works best with incremental changes rather than large complex changes that are time-consuming to change, build, test and deploy. DevOps also works best in ephemeral cloud computing infrastructures that can be scaled up and down quickly depending on short-term workload demands of supporting build, test and deployment requirements.

    While existing applications will eventually be modernized to take advantage of the cloud, greenfield applications should be designed to exploit recent advancements in cloud-based platforms and application delivery.

    The following paragraphs describe the characteristics of five levels of application maturity.

    Spaghetti applications are older, monolithic legacy application designs that tend to be large and complex, like a big messy bowl of spaghetti. This complexity occurs partly because these older apps accumulate a massive amount of code and patches over time and partly because the architectural approaches at the time they were conceived did not have modular, cloud-oriented requirements in mind. Spaghetti applications are the least capable of taking advantage of cloud infrastructures.

    Modular applications emphasize architecture designs that separate application components into functionally independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality.

    A module interface expresses the elements that are provided and required by the module. The elements defined in the interface are detectable by other modules. Modules often use a design style known as service-oriented architecture (SOA), where services are self-contained black boxes that provide capabilities to the other application modules, as a service, through a network protocol. SOA may be confused with microservices architecture.

    There are key differences between SOA and microservices architecture that are important to DevOps. Microservices are preferred over SOA architecture because microservices are more fine-grained and restricted in what they can do. SOA uses an enterprise service bus for communication, whereas microservices use more lightweight stateless protocols and APIs managed as a product.

    Changes to SOA modules usually require a new application release, while a change to a microservice usually only requires the microservice to be replaced. Migration of modular applications to the cloud may require rework to take advantage of cloud features such as autoscaling.

    Cloud-ready applications that use the twelve-factor application modular design principles are more advanced. These modular designs emphasize declarative formats for automation, clean contracts with the underlying operating system and portability between execution environments. Deployment on modern cloud platforms obviates the need for servers and systems administration, minimizing divergence between development and production and enabling continuous deployment for maximum agility.

    These characteristics and capabilities enable the application to scale up without significant changes to tooling, architecture or development practices. Cloud-ready applications can be easily mapped to virtual machines (VMs) available through cloud infrastructure services (IaaS) for VMs based on VMware vSphere or Microsoft Hyper-V.

    Cloud-ready apps do not require rearchitecting or refactoring. They offer least-effort migration to the cloud with a lower availability rate. However, workloads such as legacy databases, third-party applications and homegrown business applications that are typically not designed for clustering or high availability suffer from a single point of failure.

    Cloud-ready apps are expensive to maintain. This is primarily due to the way they consume computing, storage and network resources, even when idle. Each component of an app runs in a dedicated VM with no scope for optimization. Upgrading or patching results in downtime and makes maintenance complex and expensive. Ultimately, cloud-ready apps derive less value from the cloud than cloud-optimized or cloud-native applications.

    Cloud-optimized applications take advantage of managed services offered by cloud providers. For example, instead of running a database in a VM, they consume database-as-a-service (DBaaS). Cloud-optimized apps typically target the platform-as-a-service (PaaS) delivery model of the cloud. They are portable and can be deployed in IaaS or PaaS. This reduces the deployment footprint, offering flexibility to IT teams. These apps are elastic, with the ability to easily scale in and scale out which results in optimal utilization of resources. Upgrading, patching and maintaining cloud-optimized apps is more manageable when compared to cloud-ready apps.

    The downside of cloud-optimized apps is the learning curve involved in migrating to the cloud. Developers, operators and system administrators will have to learn new ways of deploying and managing workloads. Line-of-business applications with access to source code are great candidates for being cloud-optimized apps. They can be redesigned and rearchitected to take advantage of the cloud. Cloud-optimized apps can integrate and interoperate with cloud-ready applications.

    Cloud-native applications are the most recent iteration of applications that are born in the cloud. They take full advantage of the cloud by exploiting capabilities such as elasticity, event-driven resource optimization and faster release cycles. Apps that are in the early stages of design and architecture are perfect candidates for cloud-native.

    Cloud-native applications are designed as federated microservices, packaged and deployed as containers and managed through modern DevOps processes. When your organization needs to scale to thousands of services in the cloud, microservices application architectures offer major benefits over monolithic modular architectures, including the following:

    • Separate microservices are better suited to different technology stacks.
    • Federated microservices enable independent deployment of different parts of the system.
    • Isolated deployments add to the resilience and fault-tolerance of the system.
    • Scaling characteristics may be different for each microservice.
    • APIs are used as connectors.
    • Stateless protocols help assure seamless recovery.
    • Event-driven programming reduces overhead and process latency.
    • Antifragile practices inoculate against unanticipated failure modes.

    The target deployment environment for cloud-native applications includes containers-as-a-service (CaaS) and functions-as-a-service (FaaS). This breed of apps delivers ultimate scalability and availability. Combined with continuous integration and continuous deployment, software is delivered rapidly, which accelerates time-to-market. It brings closed-loop feedback among developers, testers, operators and end users.

    Cloud-native apps demand new skills of containerization, microservices and build and release management. However, the ROI is higher when compared to other app models. Greenfield applications that are still in the design phase are ideal for adopting the cloud-native pattern.

    Diverse Applications for Cloud Migrations

    Large enterprises moving to the cloud will deal with a diverse set of applications. Through hybrid connectivity and integration, spaghetti, modular, cloud-ready, cloud-optimized and cloud-native applications will co-exist and interoperate with each other. If you are after the benefits of modularity, make sure you do not trick yourself into a microservices-only mindset.

    Explore the in-process modularity features or frameworks of your favorite technology stack. You will get support to enforce modular design instead of having to just rely on conventions to avoid spaghetti code. Then, make a deliberate choice whether you want to incur the complexity penalty of microservices. Sometimes you have no choice, but often, you can find a better way forward.

    What This Means

    This blog is one of a series that explained how to engineer applications to be most suitable for DevOps. Topics covered in this blog series include:

    • Factors used to decide whether an application is a good candidate for DevOps.
    • Practices to engineer designs for DevOps.
    • DevOps applied to enterprise apps and software services.
    • DevOps applied to COTS systems.
    • DevOps applied to manufactured (embedded) systems software.
    • Five levels of application maturity.

    This blog covers five levels of application maturity. You can read part one here, part two here, part three here, part four here and part five here.

    For more information regarding how to engineer applications for DevOps refer to my book Engineering DevOps.

  • JFrog Acquires Vdoo to Advance DevSecOps

    JFrog Acquires Vdoo to Advance DevSecOps

    JFrog today announced it has agreed to acquire Vdoo for $300 million in cash to gain a set of analytics tools that discover vulnerabilities in application binaries.

    Vdoo’s scanning tools, infused with machine learning algorithms, will be fully integrated with the JFrog Xray vulnerability detection tools along with the rest of the JFrog continuous integration/continuous delivery (CI/CD) platform in 2022. In the meantime, the Vdoo scanning tool will continue to be made available via a software-as-a-service (SaaS) platform that Vdoo built.

    The Vdoo platform is already integrated with the JFrog Artifactory repository and JFrog Pipelines. Vdoo’s platform also is integrated with DockerHub, Jenkins, GitHub, GitLab and Azure Pipelines via REST application programming interfaces (APIs) that make the Vdoo scanning tools accessible via a command line interface (CLI).

    JFrog CTO Yoav Landman said acquiring Vdoo is critical because when it comes to implementing DevSecOps best practices, the only meaningful place to discover and remediate vulnerabilities is in the binaries deployed in production environments. As such, the Vdoo platform provides a superior alternative to both static application security testing (SAST) and dynamic application security testing (DAST) tools that scan for vulnerabilities in source code, added Landman.

    Developers require accurate intelligence that can be quickly acted upon to secure applications running in production. They can quickly take action once they know how a specific vulnerability impacts a binary, versus being told to update source code that could take days or weeks to complete, noted Landman. The Vdoo platform also makes it possible to leverage machine learning algorithms to detect zero-day vulnerabilities, malware, exploits, backdoors, supply chain risks and other threats before they become commonly known. Those vulnerabilities can be detected in everything from application binaries to firmware running on embedded devices. Vdoo is also recognized by the Mitre Corp. that oversees the Common Vulnerabilities and Exposures (CVE) database as a CVE Numbering Authority (CNA) for discovering vulnerabilities.

    JFrog Vdoo

    As responsibility for application security continues to shift left toward developers, many organizations are finding the tools that cybersecurity teams employed to discover threats don’t lend themselves to the workflows that developers have created to build applications. As a result, many of these tools are being replaced by developer-friendly alternatives that developers can invoke via a CLI as part of DevOps workflow. The goal, now, needs to be reducing the level of noise created by security tools to enable developers to focus on the vulnerabilities that specifically impact their code, noted Landman. Otherwise, developers are simply overwhelmed by a massive number of alerts generated by security tools that often don’t appear to be especially relevant, Landman added.

    It’s not clear how quickly responsibility for application security is shifting left. However, in the wake of a series of high-profile software supply chain breaches, the urgency surrounding adoption of DevSecOps best practices has increased considerably. The challenge, as always, is getting the right tools into the hands of developers at the right time.

  • Gotta Fix ‘Em All: AWS BugBust 2021

    Gotta Fix ‘Em All: AWS BugBust 2021

    Software bugs are vexing. Code reviews and error finding aren’t a particularly fun part of a developer’s job description. Finding bugs is tedious, time-consuming and hard on your eyes. Bugs not only wreak havoc on your code, they wreak havoc on your day. But what if bashing bugs could earn you a payoff greater than pride? That’s where AWS BugBust comes in.

    AWS BugBust is the world’s first global competition for Java and Python developers. The contest has two overall goals:

    1. Fix 1 million bugs and
    2. Reduce technical debt by over $100M, globally

    Code reviews and monitoring are common practice; some organizations even hold bug bashes where members come together to reveal bugs and fix them. However, fixing code is still an arduous process and there is more that could be done to make bug-bashing efforts fun and fast. AWS BugBust does both by adding in gamified points/competition/prize components!

    How does AWS BugBust work?

    The more bugs you fix, the more points you earn and the higher up in the leaderboard you get. Using Amazon’s CodeGuru, developers will compete to fix the most bugs (identified by CodeGuru Reviewer) and the most expensive lines of code (highlighted by CodeGuru Profiler). Amazon CodeGuru eases the pain of code review and error finding by automating the process. Using Machine Learning, Amazon CodeGuru will scan code quickly, identify errors and provide fix-it recommendations.

    Here is more info about the contest:

    How do you earn points?

    AWS BugBust uses Amazon CodeGuru Reviewer to analyze applications’ code to identify bugs and CodeGuru Profiler for performance issues. The bugs and profiling groups are available on the challenge dashboard and are available for participants to claim them, fix, and score points. Points are earned based on the severity of the bug (low, medium, and high)

    To score points, participants make code changes in their repositories, create a code review request, and trigger a code build. CodeGuru Reviewer will analyze the code changes as part of the build process and notify whether the code that was changed addressed the bug.

    The collective number of bugs fixed and dollars saved will be stored in the AWS Global BugJar. The totals for both metrics will show on the global leaderboard.

    Participants will receive digital badges and bespoke swag at three key milestones: 100, 2,000, 10,000 bugs fixed. Swag includes pins, t-shirts, BugJars, backpacks, and hoodies/jackets.

    When will AWS BugBust take place?

    The contest will launch Thursday, June 24. You can get started by setting up an AWS BugBust for your team.

    What’s the ultimate prize?

    The top ranking developers of the global leaderboard by the end of September 30, 2021 will receive an all-expense-paid trip to re:Invent 2021. AWS will also award the top 10 enterprises who collectively contribute the most bugs to the global BugJar through their private events with two tickets to re:Invent 2021 for their top BugBusting developers. If you’re a Java/Python developer, this competition will be like doing your job while enjoying a game-like atmosphere!

    Here are important rules:

    1. An AWS account is required to participate in the challenge (participants can create one at the beginning of the challenge or any time during the contest period).
    2. Customers who have their code bases in Java and/or Python and stored in supported GitHub, GitHub Enterprise, Bitbucket and AWS CodeCommit repositories are able to participate in the AWS BugBust.
    3. Challenge registration and console experience, overall, are much better on the desktop. Links in the console will direct to code repositories which are more easily accessible on the desktop, as well. Mobile placements will be considered for awareness, but desktop should be prioritized.

    AWS BugBust isn’t your grandma’s bug hunt. You now have machine learning capabilities on your side, including the ability to automatically find bugs for you and present the list of bugs to you – even before the challenge begins. You can make the arduous inspection process fun, win some prizes, be the hero at busting bugs and find them, starting June 24!

    We have also provided additional information about the AWS BugBust competition on devopsy.kinsta.cloud.

  • Safeguarding Composable Architecture Applications Based on API-enabled Components

    Safeguarding Composable Architecture Applications Based on API-enabled Components

    The use of composable methodologies for application development is growing rapidly. The reason: It offers many benefits that speed the development process and opens up application creation to developers of all skill levels. However, the speed and ease-of-use benefits, via the reuse of pre-built components, can introduce new security risks that traditional security management solutions might not be able to handle.

    The rising interest and adoption of composable architecture seems to be a matter of the right approach at the right time. Businesses today are under great pressure to innovate, transform, and offer new products and services. The pressure is coming from both inside organizations and from customers. Those within need applications, tools, and services to increase productivity, boost efficiencies, and cut costs. Customers want fast service, improved engagement, and quick responses to any queries and questions.

    A composable approach to application development helps businesses deliver the needed solutions at the pace of modern business change. It accomplishes this by using composable entities that offer self-contained business capabilities. These elements make use of APIs and can be assembled and combined into larger applications.

    Bolstered by other industry trends

    Another reason for the popularity of composable application development is that it is a good match and complements other application development trends.

    For example, its usefulness is enhanced by low-code/no-code development methods. Low-code/no-code saw great adoption during the pandemic. Businesses realized they needed to be more responsive to fast marketing changes, and their at-home workforce needed easy-to-use solutions.

    The surge in their use continues this year. The low code development technologies market is projected to grow by 23% this year over last.

    Many of the reasons companies cite for moving to low code are similar to why they use composable application architectures.

    Namely, professional developers work faster, and they can spend more time on higher-level development problems. And both low code and composable methodologies let individuals and business groups with limited or no development expertise create their own powerful applications.

    So, in many ways, the two technologies go hand-in-hand in many organizations.

    Similarly, many of the underlying rationale and principles for using composability align with the other cloud-native methodologies. Specifically, with a cloud-native approach, applications are broken into loosely coupled microservices and container elements that are then assembled into a larger application. Specific elements in a cloud-native application, such as a front-end application or a business process, can be standardized and made available as a composable component in a cloud-native application.

    What’s needed for security?

    Enabling development using composable elements centers on APIs. Specifically, with respect to composability, Gartner notes that businesses “seeking to kick-start efforts to turn an organization into a composable business” should:

    • Enforce composable application design by ensuring application development teams use available external and internal API products
    • Educate teams about how to exploit existing applications and platforms for composability by using application APIs and low-code development and integration platforms.

    Hence, security efforts must change from traditional approaches to ones that are more API-centric. Solutions must observe all user activity and API interactions, then act on unexpected user and API behaviors.

    Solutions that address composable application security must offer infrastructure, services, and code-level threat analysis in a single platform to facilitate collaboration and expedite threat resolution to meet the needs of modern DevSecOps approaches to application development and security.

    Such capabilities are critical given the complexity of modern cloud-native applications. In many cases, when creating applications with composable elements, hidden inter-dependencies can arise. Traditional security solutions often will not be able to detect such issues or trace the source of problems down to the composable element level.

    Furthermore, while each element of an application may be secure, the interplay between the composable elements and the data exchanged between them can introduce risks that need a more API-centric solution which understands the greater application context. 

  • Atlassian Delivers on Forge App Dev Platform Promise

    Atlassian Delivers on Forge App Dev Platform Promise

    Atlassian this week made available a Forge platform for building applications that complements its existing portfolio.

    Mike Tria, head of platform engineering for Atlassian, said Forge is intended to provide an application development environment to both IT organizations and third-party partners. It provides developers with access to an integrated Atlassian DevOps toolchain to accelerate testing, deployment, debugging and to capture log data, added Tria. Forge also presents developers with a command line interface through which they can be onboarded to the Atlassian cloud where Forge runs to access documentation and application samples. It uses OAuth 2.0 to ensure applications deployed on the Atlassian cloud only access data they have permission to access.

    The overall goal is to provide developers with a more modern application development environment as an alternative to the application development platform the company previously made available.

    Once an application is built, developers can then publish their applications on the Atlassian Marketplace as free or commercial offerings. There are already more than 3,500 Forge apps that were created during a beta process that began late last year. Forge will soon be extended to the rest of the Atlassian portfolio, noted Tria.

    Forge is intended to complement an Open DevOps initiative launched earlier this month that tightens integration between the Jira project tracking and management tools provided by Atlassian and a wide range of other tools commonly employed by DevOps teams. The goal is to not only make it easier to correlate issues that are listed in Jira with artifacts found in various software platforms, but also to collect data from DevOps tools to automatically update Jira.

    That data will then be employed to inform key performance indicators (KPIs), based on graphs that Atlassian provides within Jira, to keep track of value streams. Rather than having to acquire a separate value stream management (VSM) platform to track software development progress, the insights needed to understand the impact of, for example, a delay to one project becomes a dividend of using Jira.

    Like most providers of software-as-a-service (SaaS) applications, Atlassian has been making available a platform for building applications on top of the same platform it employs to build its own applications. Atlassian claims there are more than 1,200 partners building applications in addition to internal IT that teams that have built custom extensions to its applications. Atlassian has already shown a proclivity for acquiring independent software vendors (ISVs) that build applications on its platform. As part of the overall Forge initiative, Tria said Atlassian will be working more closely to identify the white space that won’t be addressed by the Atlassian product roadmap at some future date.

    In the meantime, independent software vendors and internal IT teams will need to determine to what degree they will prefer to stand up their own application development environment versus opting to be dependent on Atlassian. In theory at least, applications built on Forge should be more tightly integrated with the rest of the Atlassian portfolio. The only potential downside is, of course, any potential conflict that might emerge with a provider of an application development platform that also happens to sell application software.