devopsy.kinsta.cloud

Category: Blogs

The Gamification of Everything
Cross-pollination, for the non-scientific, is one of the key foundations of biodiversity on Earth. It is evolution in action—responsible for reinforcing the traits that make plants stronger and ensuring the survival of many species.

On a far smaller scale—but equally crucial, from a business point of view—technology applications that move across industry delineation generally gets stronger. The traits that make great tech awesome in one domain combined with the unique use cases and experience of another domain result in more powerful and more flexible technology. And it’s not just a one-way street. Tech often moves back and forth across industry segments, and each time it crosses the line, its DNA improves. That means that, ultimately, the original domain tends to be strengthened by cross-pollination, too.

This is exactly what’s happened with gaming development technology in recent years. And I’m not just talking about best practices. I’m talking about actual purpose-built gaming development technology that’s spread across and penetrated into industries like automotive, e-commerce, entertainment, architecture, real estate and more.

This cross-pollination has left top-tier gaming tech players like Epic’s Unreal and Unity in a vastly superior position. In fact, it seems that cross-pollination is becoming an integral part of the growth strategy for these and other gaming tech companies. They’re not only betting their tools will shape the next generation of user experience in multiple industries–they’re also making strategic acquisitions that will make this happen.

What Does Cross-Pollination Look Like?

Cross-pollination of gaming tech takes a number of forms–some quite overt, others more subtle. For example:
- The gamification of mobility–Gaming tech is bringing a new level of interactivity and visualization to the automotive industry. For visualizing self-driving, safety testing, visualizing automotive components, creating online showroom visualizations of vehicle interiors and more–gaming tech is deeply integrated into automotive development, manufacturing and retail.
- The gamification of entertainment–Game development tools are revolutionizing the way entertainment companies develop content. From scene development based on a gaming methodology and gaming engines, to an entire popular series shot in one location using Unreal–gaming tech has radically changed the scene and series development pipeline.
- The gamification of business software–The gamification of business software is streamlining processes, training and workflows. From companies like Invrsion, which offers game-like virtual reality tools for retail, to Salesforce, which adopted a game motif for key training—business functionality augmented by gaming tech and gaming user experience enhancements are becoming standard.
- The gamification of education–Learners learn best when they’re having fun–and also when they have goals, targets and achievements to reach for. Sites like Khan Academy and apps like Duolingo have brought gaming tech and methodologies into the virtual classroom, changing paradigms for educators and learners alike.
- The gamification of everything else–Shopping for clothes online during lockdown? The functionality that lets you “try on” garments is based on gaming tech. Designing a new pharmaceutical molecule using VR augmentation? Gaming tech. Urban design? Yep—gaming tech. And the list goes on.
Why Gaming? A Unique Technology Incubator

The question that companies in any industry should be asking is: why is gaming able to create such powerful, flexible and inspiring tech that lends itself so well to cross-pollination?

The answer is multifaceted. First off, gamers are out-of-the-box thinkers, to say the least, and game developers–well, they broke the box before the gamers even got there. Gaming tech was born in a development environment on steroids—tight schedules, computing intensive processing, insane competition and frequent release cycles. This makes for a space that’s both receptive to new tech and open to new ways of doing things.

Secondly, gaming is a ridiculously dynamic industry that is undergoing incredible growth, and the pandemic has only accelerated this trend. More money coming in translates to more investment in developing, improving or acquiring tech, as well as to launching more and more new games.

Finally, in the gaming world, human resources cross-pollination is built in. Game developers move between studios all the time. This spreads tech advancements like–pardon the sensitive reference–a virus. Because if something worked well for you in one job, you’re going to want to use it in your next position.

The Takeaway

In both the natural and business worlds, cross-pollination is necessary for survival. Gaming tech is leaking into other industries for one key reason: it is frequently superior. And this cross-pollination of gaming tech benefits both the industries that adopt it and the gaming industry itself.
June 14, 2021
Majority of Orgs Lack Visibility Into Container Vulnerabilities

Today’s blend of third-party application dependencies and polyglot software development often makes assessing risk difficult. With many new cloud-native deployment models, it can be tricky to discover potential vulnerabilities. These threats take the form of insecure default settings in Kubernetes, over-permissive states, CVEs that threaten container integrity, and other vulnerable conditions.

Plugging gaps throughout the cloud-native strata is now crucial to avoid exposing data and breaking privacy regulations. Yet, gaining visibility into these holdings is challenging, and traditional application security practices may not cut it within a cloud-native context.

A new 2021 CISO Report released by Dynatrace, “Precise, automatic risk and impact assessment is key for DevSecOps,” demonstrates increased false positives and a general lack of real-time container runtime vulnerability scanning among enterprise IT departments worldwide. Of the 700 CISOs surveyed, most report that microservices, containers and Kubernetes have caused security blind spots across their organizations.

Below, we’ll cover the major takeaways from the study to see why new cloud-native development models are leaving security gaps. We’ll consider how CISOs can increase security throughout the cloud-native IT stack while still reaping the rewards of container-based delivery models.

Cloud-Native Security Blindspots

Adopting new container-based technologies may introduce multiple nuanced security implications. Of the tech leaders surveyed, 89% report that microservices, containers and Kubernetes have created new vulnerabilities within their organizations.

Engineers are shipping code to maintain release velocity and to meet the demand for digital innovation. In the process, 28% of CISOs say application teams sometimes bypass vulnerability scans to speed up software delivery. Due to these realities, it’s no surprise that 71% of CISOs admit they are not fully confident code is free of vulnerabilities before going live in production.

As some teams bypass security pre-production, it follows that more aren’t applying holistic security scanning during production. As a result, nearly all organizations (97%) lack real-time visibility into runtime vulnerabilities, found the report.

Adding to the number of cloud-native blindspots is information overload. The report calculated that, on average, an organization receives a staggering 2,169 new alerts of potential application security vulnerabilities each month. Out of this high volume of alerts, 77% of CISOs say they are mostly false positives and not actual exposures.

Due to minimal testing and a high number of false positives, organizations are likely to leave many vulnerabilities unpatched. To make matters worse, developers, pressed for time, may lack the bandwidth to resolve known issues.

Faster Delivery, Harder Detection

Much of the setbacks in vulnerability detection may lie in a general shift toward new ways of working and faster delivery cycles. For example, 63% of CISOs reported that DevOps and agile methodologies are making it harder to detect and manage vulnerabilities.

In addition, 74% of CISOs say traditional security controls such as vulnerability scanners no longer fit today’s cloud-native world, and 77% of CISOs agree that automation could help. This could involve replacing manual deployment, configuration and management with more automated approaches. Others agree that security-as-code is required to ensure high container security best practices.

Another result of more frequent delivery is increased over-reporting. Of the total security vulnerability alerts received per month, CISOs report that only 42% of these alerts require action. More rapid release cycles could thus exacerbate already crowded vulnerability detection systems.

Who Owns Vulnerability Management?

Only 3% of organizations have real-time visibility into runtime vulnerabilities in containerized production environments, the study found. In reality, vulnerability scanning in production is only happening once a month or less within 68% of organizations.

To compensate for this gap, most CISOs believe the onus is not on the security team but the application and DevOps teams to manage and respond to vulnerabilities—85% of CISOs believe these groups should hold responsibility for vulnerability management. These findings come to light as other stakeholders advocate for increased full-cycle developer control and encourage the DevOps mindset across roles.

Handing more control to developers sounds good, yet, 64% of respondents say developers don’t always have time to resolve vulnerabilities before code goes into production. As a result, over one-quarter of application teams bypass vulnerability scanning entirely. Often, engineering teams may not frequently sync with security groups, and DevSecOps principles are not yet pervasive throughout all organizations.

The report also highlighted the fact that existing security tools are often ineffective; 69% of CISOs say security tools slow down DevOps because they only focus on one state of the software delivery cycle.

Cloud Use Requires Security Repositioning

As cloud architectures rise in prominence, organizations are adopting cloud-native tools like microservices, containers and Kubernetes. There is also the chance of multi-tool conditions further complicating the vulnerability scanning process. With more systems to protect than ever before, teams may have to reposition their approach to vulnerability detection.

“The increased use of cloud-native architectures has fundamentally broken traditional approaches to application security,” said Bernd Greifeneder, founder and chief technology officer at Dynatrace. “This research confirms what we’ve long anticipated: manual vulnerability scans and impact assessments are no longer able to keep up with the pace of change in today’s dynamic cloud environments and rapid innovation cycles.”

The Global CISO report, “Precise, automatic risk and impact assessment is key for DevSecOps,” from Dynatrace, queried 700 chief information security officers (CISOs) on their monitoring practices concerning vulnerabilities. To review the report’s full findings, you can download it here.

June 14, 2021
Cortex Taps GitLab to Help DevOps Teams Manage Microservices

Cortex, a provider of a platform for tracking ownership of microservices, this week announced its platform can now import services from the GitLab continuous integration/continuous delivery (CI/CD) platform.

Anish Dhar, Cortex CEO, said the company’s platform is now integrated with more than 30 tools that are regularly employed by DevOps teams, including offerings from GitLab, Datadog, Sonarqube, Snyk and PagerDuty, as well as open source platforms such as the Kubernetes container orchestration engine and the Istio service mesh.

Designed for site reliability engineers (SREs) and other DevOps professionals, the Cortex platform eliminates the need to rely on spreadsheets to manually track ownership of microservices. Instead, Cortex imports data residing within the tool employed by developers to surface who within an organization is responsible for maintaining which microservices.

In addition, a Cortex dashboard enables DevOps teams to see which developers are on-call in the event of an unexpected incident, the latency rate microservices are experiencing and which vulnerabilities have yet to be remediated.

Grades can also be assigned to specific microservices based on metrics that are associated with a specific microservice. That approach allows DevOps teams to apply gamification techniques using a scorecard to encourage developers to continuously improve their microservices, noted Dhar. That approach will also make it apparent to other developers which microservices running in a production environment can be most reliably employed, added Dhar.

At the core of the platform is Cortex Query Language (CQL), a domain-specific language that allows DevOps teams to define granular rules that can be applied to, for example, on-call rotations, security vulnerabilities, package versions, service level objectives (SLOs) and the overall health of the microservice. Engineers can employ code in the form of YAML files to set reliability standards across teams and types of services through direct integrations with a variety of tools. In effect, Cortex provides a reliability-as-code platform, said Dhar.

As responsibility for applications shifts further left, each development team is being held accountable for the life cycle of any microservice or application they create. The challenge enterprise DevOps teams are encountering is that when there are hundreds, even thousands, of microservices, it’s difficult to determine who on the development team is responsible for a specific microservice. Rather than trying to keep track of the relationship between development teams and microservices using a spreadsheet, Cortex is making a case for a tool that automates that discovery and tracking process.

Most organizations today are embracing microservices to build and deploy more flexible applications at varying rates. However, it’s only a matter of time before they find themselves trying to navigate a web of interdependencies between microservices that can’t be managed using spreadsheets. DevOps teams, of course, might be inclined to use their skills to create their own tool for tracking microservices. However, given all the tasks at hand, maintaining a custom platform for discovering and tracking ownership of microservices is likely something better done by a vendor willing to maintain and support a purpose-built tool.

June 11, 2021
How to Gain Greater Value From DevOps

DevOps is more than just deployment and management. Fully leveraging the DevOps team and their activities can actually enhance operations and improve customer satisfaction.

Be Proactive, Rather Than Reactive

Say you deploy a new version, encounter some problems and then react. What if you could stay at least a step or two ahead by becoming more proactive?

Check your metrics and look for trends. You can spot rises in error rates or latencies over time and identify problems just as they are bubbling up. Ideally, you’ll identify them when they are merely minor issues, not when you’re already required to hit the panic button or roll back. Looking ahead to see what’s around the corner puts you in a much better place.

Use Feedback to Improve Operations

While it’s true that investing time and resources to automate tasks, such as deployment, is a good thing, it’s even better to focus on another high-value DevOps activity—bringing insights from operations into your development pipeline.

Incorporating feedback and ideas into your processes puts you in a much better place, especially because there are already tools out there to help you do those deployments and other tasks pretty easily. For example, once you’ve packaged your application into a container, you just need to push a few buttons to set up automatic scaling, load balancing and routing. With all of that automated, you can focus on what’s really important—your application.

Track Customer Behavior

Here are two gems—both easy to set up and use, from the same GitHub author—that you can use to track your customers’ behavior, monitor usage and get better insights to improve operations.

Ahoy—Use this to track user visits to your web page to determine specific named events that you want to add to your code. You can do this from either the server side and a controller, from JavaScript, or via a simple API. It uses two tables that you can easily query, plus some smart built-in data visualization capabilities.
Blazer—Use this to gain visibility to your database by just adding a mount point to your routes file so that you can access the web application. It provides an easy interface to do SQL queries and show the results.

Check the Metrics Often

Once you get these tools set up, don’t stop there. Check the metrics—weekly if possible—and see what the trends are. Ask questions. The cool thing about operations—unlike engineering and writing software where you’re trying to solve one problem—is it’s not always well defined. You may not even know what questions to ask at first. However, diving into the metrics and seeing what patterns emerge from the use and events will not just benefit your customers, but also feed back into your development cycle. This empowers you to go back and reevaluate decisions made earlier on and learn where you should direct your attention and energy going forward.

Be sure to enhance your focus on where DevOps can actually take you. It’s not just about writing automation and deployment scripts. The synergy of analysis and software is the future of DevOps.

June 11, 2021
Learning ‘The Second Way’ of DevOps – Continuous Feedback

As indicated in my prior blog Learning the ‘First Way’ of DevOps–Continuous Flow, many organizations are struggling to realize well-engineered DevOps, even the ‘first way’ of DevOps – continuous flow.

The first way of DevOps, continuous flow, is the foundation for DevOps. Once mastered, an organization will naturally want to master the second way of DevOps to achieve greater benefits that continuous feedback offers when engineered well. DevOps is an evolving body of knowledge. There is no one-stop shop that covers all roles and the complete range of skills required for DevOps. A DevOps-competent workforce requires an ongoing commitment to DevOps skills development and mastery. Enterprises must approach DevOps training strategically to leverage training resources to their best advantage.

Learning Continuous Feedback

There are no training resources dedicated solely to the second way of DevOps—continuous feedback. Many of the same resources used to learn the first way of DevOps have some relevant information, though. DevOps monitoring, release automation and security tools publications, articles and tool vendors are a good source. A DevOps expert who is experienced with mature DevOps can select the training information that is relevant to the specific continuous feedback tools and feedback metrics used by the enterprise.

Why This is Important to Engineering DevOps

Continuous feedback requires a mature understanding of DevOps concepts and practices. Specific skills are needed for implementation and operation of advanced monitoring tools and practices for application performance, database performance, advanced continuous testing, advanced release management, infrastructure performance and continuous security.

How Is Learning Continuous Feedback Accomplished?

The following are recommended engineering practices for learning Continuous Feedback.

Roles and responsibilities are assigned to experts for defining a training program for DevOps continuous feedback (e.g., DevOps sensei, training PM, evangelist). Continuous feedback DevOps skills gap assessments are conducted periodically. Dev and Ops training strategies are designed to address gaps and priorities of the organization for DevOps continuous feedback. A training budget that includes allocations of expenses and time allocations per role exists to support continuous feedback. Continuous Feedback goals and SLAs are defined for each role.

Recruiting job profiles match skill requirements for DevOps skills relevant for continuous feedback. Training resources are available and visible to those that need continuous feedback training. Training goals set for teams and individuals include goals for continuous feedback. Incentives and recognition programs support Continuous Feedback training. Continuous feedback training progress is tracked and visible.

What Is Needed to Implement Learning?

The following are recommended engineering practices for implementing a learning program for continuous feedback.

Assign roles and responsibilities to experts for defining a training program for DevOps continuous feedback (e.g., e.g., DevOps sensei, training PM, evangelist). Conduct a continuous feedback DevOps skills gap assessment. Define a training strategy that best addresses the gaps and fits the needs and priorities of the organization. Define a training budget that includes expenses and time allocations per role and skill.

Determine which skills and roles can be covered by inexpensive self-study resources. Determine which skills and roles warrant more costly commercial training Identify training goals for each role. Ensure recruiting job profiles match skill requirements for DevOps skills that are most relevant to the organization’s strategic goals.

Put in place the means to make training resources visible and available. Set training goals for teams and individuals. Put in place incentives and recognition programs for training. Track training progress.

Some of the best sources of DevOps training resources are listed below:

1. The DevOps Institute
2. Partners of The DevOps Institute, such as Learning Tree International and Xellentro
3. Udemy.com
4. Recorded talks and publications of IT Revolution.
5. Books such as my own “Engineering DevOps,” by Marc Hornbeek.

What This Means

To accomplish the benefits of the second way of DevOps—continuous feedback requires a commitment to continuous learning and mastering skills beyond what is needed for the first way of DevOps–continuous flow. Specific skills are needed for implementation and operation of advanced monitoring tools and practices for application performance, database performance, advanced continuous testing, advanced release management, infrastructure performance and continuous security. Organizations need a trained workforce to succeed with DevOps. Organizations must approach DevOps training strategically and continuously to leverage training resources to their best advantage. To learn more about my blueprint for learning all things DevOps, refer to my book Engineering DevOps.

June 11, 2021
Working Lunch

June 11, 2021
CloudBolt Adds Cloud Cost Tool to Hybrid Management Platform

CloudBolt Software this week added cost management capabilities for Amazon Web Services (AWS) and Microsoft Azure public clouds along with codeless integrations with additional platforms to its hybrid cloud management platform.

Grant Ho, chief marketing officer for CloudBolt, said the Spring Release of the company’s platform, now generally available, enables IT operations teams to rely much less on custom code to integrate the various elements of a hybrid cloud computing environment. The Spring edition adds support for the VMware vRealize Automation 8 automation platform, the configuration management database provided by ServiceNow as a cloud service and the IP address management platform from SolarWinds.

In the wake of the COVID-19 pandemic, CloudBolt is betting more organizations will look to centralize IT management as part of an effort to reduce the total cost of IT. The cost management capabilities added to the platform enable IT teams to position themselves as more of an independent arbiter of where certain classes of workloads should run, based on cost, at a time when organizations have never had as many options as they do today, noted Ho.

A recent survey published by CloudBolt found 80% of respondents are prioritizing real-time insight into cost optimization and security remediation. A total of 71% want self-service to be easy for end users, while 62% want an approach to integration that doesn’t require deep domain knowledge or special expertise.

A full 94% of respondents also noted hybrid cloud computing will be critical to digital transformation. A total of 92% also noted that empowering end users through self-service IT is a digital transformation accelerator, while 99% said successful automation depends on streamlining integrations.

More than three quarters (78%) noted they lack the visibility necessary to optimize cloud deployments. More than half (56%) also admitted their self-service offerings fail to meet user needs and more than three-quarters (76%) still rely on some form of custom coding when it comes to integration.

Most enterprise IT organizations are trying to strike a balance between cost and flexibility as IT environments become more distributed. Each time a new platform is added to an IT environment, the total cost of IT rises because additional consoles for managing those platforms need to be staffed. The challenge is finding a way to centralize the management of IT in a way that reduces the number of consoles that have to be mastered without requiring every business unit to standardize on a platform that locks an organization into a single provider.

It’s unclear to what degree IT organizations will rely on traditional IT service management (ITSM) platforms manned by administrators versus DevOps platforms deployed by site reliability engineers (SREs) to achieve that goal. However, one way or another, the cost of distributed computing environments needs to be reduced, even as they are becoming more complex. The primary issue now is deciding how best to achieve that goal in an IT environment where every application owner tends to view themselves as master of their own IT domain.

June 10, 2021
Lightbend Launches Serverless Managed DevOps Service

Lightbend today unfurled a cloud service based on a serverless framework that provides developers with a managed DevOps platform to build applications that dynamically scale resources up and down as required.

Brad Murdoch, executive vice president for strategy at Lightbend, said Akka Serverless provides access to its Java development platform environment that runs atop Kubernetes via a declarative application programming interface (API) based on the gRPC protocol. Support for additional open APIs, such as GraphQL, is planned, added Murdoch.

At the same time, Lightbend revealed today that Jonas Bonér has assumed the role of CEO in place of Mark Brewer. Previously CTO and founder of the Akka Project, Bonér is a co-author of a reactive manifesto that defines the core principles required to build applications using a reactive programming model.

Akka Serverless, available via an open beta program that provides access to limited amounts of storage, is scheduled to be generally available in the fourth quarter on the Google Cloud Platform (GCP), with support for additional cloud services planned.

The service is made possible because Lightbend extended an existing open source Cloudstate serverless framework to create a platform-as-a-service (PaaS) environment to support large amounts of distributed stateful data that developers employ to build applications, noted Murdoch. That capability overcomes the performance limitations of existing function-as-a-service approaches, based on other serverless computing frameworks, that don’t support stateful application development, added Murdoch.

In fact, one of the reasons that adoption of serverless frameworks has been limited thus far is the inability to be employed within the context of a stateful application that requires a lot of access to data, said Murdoch.

Lightbend addressed that issue by enabling event sourced entities persist each change in state as an event that Akka Serverless writes to a journal. That journal can be used to replay events to reconstruct state at a particular time, debug or provide an audit. At runtime, a key distinguishes each entity instance from all others.

Akka Serverless is the latest in a series of managed DevOps services that automatically scales as developers request new resources. There is no need for developers to configure and manage a database on which to build their application. Many organizations are migrating to these services because they would rather focus their time and effort on building applications versus managing a DevOps platform, said Murdoch.

It’s not clear to what degree organizations will embrace managed DevOps services, which are starting to appear on various cloud platforms. However, the implication is that by choosing these types of services, organizations may not need to hire, for example, as many site reliability engineers (SREs). The challenge, however, going forward is that most of the managed DevOps platforms are currently tied to a specific cloud service at a time when most organizations are routinely using more than one cloud.

Of course, developers will need to continue to manage continuous integration (CI) processes, but, in time, the continuous delivery side of the DevOps equation may be incorporated within a managed service. Regardless of the path forward, as DevOps processes continue to become more automated, the pace at which applications can be deployed is about to significantly accelerate.

June 10, 2021
Get the Benefits of Low-Code Without the Risks

Today, more than 300 vendors and various platforms offer different flavors of low-code solutions. However, the majority of these low-code tools are really no-code tools that benefit individuals or groups trying to solve a specific program. The list of benefits of low-code tools in your environment is long and compelling; however, there are security risks that businesses should be aware of when working with these powerful tools.

When evaluating or using a low-code tool, it’s important to remember that while low-code tools abstract the process of writing code, code is still being written. Applications created with low-code tools are susceptible to the same attacks as any other web application. However, companies don’t have control over the code generated by a low-code tool, so the burden of developing secure applications is largely shifted to the low-code tool vendor. Therefore, the best way to minimize risk when using a low-code vendor is to properly evaluate that vendor’s security practices and test applications created using these tools as vigorously as you would any application developed using a traditional/pro-code approach.

Risks to consider include access control and authentication (permissions, multifactor authentication), data security (encryption in transit and at rest) and application security from vulnerabilities and attacks (network security and intrusion detection). Other risks to consider are risk mitigation covering areas such as DDOS (distributed denial of service) attacks, backup and disaster recovery, and security incident handling. Responsibility for management of these risks belongs to the low-code vendor, the hosting provider and the company using the low-code tool.

The following tips should be considered when bringing new low-code tools into your environment to minimize security risk. Remember, it’s critical to perform due diligence of the vendor. Items to consider include:

Hosting Platform: Be sure the vendor is using a reputable hosting provider, ideally Amazon Web Services (AWS), Google Cloud Platform, Salesforce or Microsoft Azure. Leading players will offer secure, highly available platforms that address the aforementioned risks and will have completed third-party audits and certifications demonstrating their commitment to security.

Vendor Infrastructure Management: Low-code vendors typically have some level of responsibility for management of the upper tiers of the overall stack; this is generally referred to as the shared security model. Review the vendor to ensure they have solid controls and processes in place to properly manage and secure the infrastructure. Ideally, the vendor regularly submits to some form of recognized audit, such as a SOC 2 Type 2 or ISO-27001. This helps ensure controls and processes are in place in areas such as security, availability, confidentiality, privacy and processing integrity to address the aforementioned risks in the area of the hosting platform the vendor is responsible for.

Formal SDLC: The vendor should follow a documented software development life cycle (SDLC) and change management process used for the development of their low-code tool. A good SDLC process includes using a source code management system, dependency checking process, static code analysis, automated unit and regression tests, peer code review, secure coding practices training, application vulnerability scanning, quality assurance testing process and third-party penetration testing.

Policies and Processes: Documented policies and processes covering information security, business continuity, disaster recovery, security incident handling, infrastructure hardening and more should be in place at the vendor. This helps demonstrate that the vendor is committed to providing a secure, highly available and high-quality offering.

The company adopting the low-code tool itself should also consider internal processes and how it’s using the low-code tools. Items to consider include:

Formal SDLC: Even though the company uses a low-code tool, there’s still the need to follow a formalized SDLC. It’s important for the company to emphasize and embrace secure programming practices, even for low-code developers. Low-code tools have the ability to implement customer-developed code snippets or components and it is recommended companies follow programming standards and secure programming practices as outlined by the Open Web Application Security Project (OWASP) foundation. Another area of emphasis that can sometimes be overlooked is the need for testing, including functional and security-oriented testing.

Security Testing: Consider performing a penetration test of the completed low-code application. While ideally, the vendor has performed these tests on the tools itself, it’s a good idea to also perform one on the completed low-code application.

Access Control and Authentication: Configure access and permissions according to the least privilege model. Leverage advanced authentication mechanisms like multifactor authentication and single sign-on where possible. Ensure an access removal process is in place to remove access for terminated employees.

Data Security: Verify the application is configured to use HTTPS and that all databases are encrypted. Low-code vendors may or may not provide a database, and either way, the company likely has some level of responsibility for securing the data, regardless of who is hosting it.

Policies and Processes: Documented policies, processes and related training for team members helps mitigate risk. Some level of formality is recommended for documentation and training for the SDLC, business continuity planning, disaster recovery and security incident handling. For example, the team responsible for the low-code application needs to know how to handle a security incident if one occurs, whether it’s due to an issue in the low-code application, the low-code tool or the hosting infrastructure.

The benefits of low-code tools far outweigh the risks of introducing these tools into your environment, but with a little effort up front, you can save a lot of headaches down the road.

June 10, 2021
Why API Quality Is Top Priority for Developers

It is no secret that web APIs have become increasingly important to the operation of modern businesses. According to RapidAPI’s Developer Survey and Insights report, 61% of developers used more APIs in 2020 than 2019, with 71% planning to use even more in 2021. We are no longer tied to a small number of monolithic service providers. Businesses tend to gravitate toward specialized managed services, such as billing and authentication, which are backed by APIs. Business models for new products and services are constructed based on APIs. Trust has become a necessity for APIs. APIs that perform consistently and with high quality earn trust, and those that do not are abandoned for a competitor.

Why Does Quality Matter?

If a market exists for an API, it’s a given that there will be competition. To remain competitive, APIs must build and maintain trust with their consumers; sales and marketing can only go so far. The highest quality APIs will inevitably capture the largest slice of market share. Quality isn’t a destination, either—it is a collection of goals that require continuous investment.

What Does Quality Mean for an API?

Just like the code that drives an API, the quality of an API itself is quantifiable. The following facets describe some broad categories used to measure API quality. The weight of each facet will vary depending on how business-critical the API will be when in production.

Resilient. An API is resilient when it continues to operate in the face of adverse conditions. Can an API continue to operate (even at reduced capacity) if the database is down? How does it handle network traffic spikes?

Robust. A robust API is liberal in what it accepts, but conservative in what it sends. Will it crash when presented with a poorly formatted request, or respond with instructions on how the caller can fix the problem themselves? Can the code be restructured without breaking the API contract?

Secure. API security is vital in most deployments. Are efforts made to check for OWASP Top 10 Web App security risks? Are open source vulnerabilities known and addressed in a timely manner? Are secure endpoints gated with authentication?

Discoverable. APIs that are well documented and well structured are much easier to consume and integrate with other services.

Consistent. A consistent API is one that changes without negatively impacting existing consumers. Changes are backward compatible or versioned as new features are introduced. API consumers should know far in advance if a breaking change will be coming if it cannot be avoided.

How Do I Get There?

Processes, tools and, most importantly, culture, are the key to high-quality APIs. Let’s explore how we can approach each API quality facet.

Resilient. Processes such as chaos engineering, load testing and manual quality assurance can uncover situations where an API is failing to handle unexpected situations. Deploying your API to a cloud provider with a compelling SLA instead of your own hardware and network shifts the burden of infrastructure resiliency to a service, freeing your time to build features for your customers.

Robust. A comprehensive suite of automated tests isn’t always sufficient to provide a robust API. Edge cases, unexpected code branches and other unplanned behavior may be triggered by requests that were not considered when writing the test suite. Traditional automated tests should be complimented by fuzz testing to help uncover hidden execution paths. Canary and blue-green deployments can further expose your API to the real world in a limited manner and prepare for when even more unexpected requests will hit.

Secure. API security is a moving target. It is expected that most APIs are built on layers of open source libraries and frameworks. Software composition analysis is a necessity to stay on top of zero-day vulnerabilities by identifying vulnerable dependencies as soon as they are discovered. OWASP guidance is a must-have—directing API developers to implement attack mitigation strategies such as CORS and CSRF protection. Application logic must be well tested for authorization and authentication.

Discoverable. For REST APIs, the OpenAPI initiative provides a consistent language for describing the API. Many frameworks, such as Spring Boot, can even generate OpenAPI documentation directly from your code. gRPC-based APIs offer similar benefits by providing both instructions for accessing the API and building the clients to communicate with it. Adding support for GraphQL allows developers to connect multiple APIs together with consistent tooling. Whichever direction you choose, it is vital to keep API documentation up to date and accessible.

Consistent. To be consistent, the API development process should make incompatible changes obvious. Code reviews can catch many breaking changes right at the source. API contract testing and integration testing can be used to discover API changes as part of the build. When working in a microservices environment, staging environments may alert engineers if an API change will cause problems before production.

Quality Builds Trust

According to the RapidAPI survey, 58% of executives said participating in the API economy was a top priority for their organization. The figure was even higher in certain industries such as telecommunications, where the number is 89%. Whether you are building APIs for internal use or for public consumption, your goal should be to earn the trust of API consumers. Investing in the culture, tools and processes to build quality APIs will pave the way to building and maintaining that trust.

June 10, 2021