Category: Features

  • Improving Software Security in 2022

    Improving Software Security in 2022

    The recent Log4j vulnerability showed just how quickly a security bug could disrupt not just an industry, but the entire world.

    Organizations, especially federal agencies, will always find themselves at some level of risk, but they can also do more to mitigate those challenges. In November 2021, the Biden administration issued a directive through the Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA) to fix hundreds of software and hardware vulnerabilities. 

    While this effort created an immediate call-to-action to patch known security risks, organizations from all industries must constantly manage known and unknown threats. A study released in July 2021 found it took organizations an average of 205 days to fix critical vulnerabilities, a timeframe that provided bad actors a wealth of opportunity to conduct serious damage.

    Agencies must adopt a more proactive approach to cybersecurity by improving software code quality. Let’s look at how to do that.

    An Ounce of Prevention

    Shaking up the status quo does tend to raise a few eyebrows, but the truth is that security programs should be in a constant state of continuous improvement. Today, our security programs work in an overly reactive state that relies too heavily on mitigation once a threat has emerged.

    Emphasizing a preventative approach may not be widely understood outside the security team, especially when an agency has a relatively clean security record. It might be seen as something that isn’t broken and, therefore, doesn’t need fixing. In this instance, getting leadership buy-in at all levels of an agency is important.

    Some pertinent points security executives should emphasize to change security culture inside their organization include:

    • The time and cost savings achieved through preventative measures, such as role-based training and related tools, as opposed to the potential cost of a critical incident.
    • Finding and fixing software vulnerabilities as code is written keeps releases on time with fewer showstoppers from the security team.
    • Preparing for and preempting potential security risks from the development team to release saves time and money overall. 

    Shifting Left of Left

    Shifting left has been popular in Agile and DevOps environments for over a decade. It involves testing small software components as early as possible rather than waiting until the end of the sprint.

    To create more secure code, organizations need to start left of left, eliminating common vulnerabilities as early as possible to create a safer user experience. 

    Starting left of left is a developer-first concept and requires organizations to get serious about uplifting their engineering cohort, placing emphasis on the creation of high-quality code. Security-aware developers are worth their weight in gold, and they need support in the form of job-relevant, hands-on training in secure code as well as the ability to provision the right tools. The opportunity to be mentored by more experienced developers will also foster an environment where code is crafted with a security-first mindset and the precision required to take software to the next level.

    One key area that often gets overlooked is the user experience; particularly with regard to how users access information.

    Security misconfigurations accounted for 21% of cloud-based data breaches in the past year, and amateur-hour errors (like storing passwords in plaintext, for example) resulted in serious productivity and customer trust losses. To avoid these errors, aim for a secure user experience that weaves tight security into a flow that makes sense. Adding more barriers—complex password requirements, a CAPTCHA, a horde of flesh-eating zombies—can turn users away. On the other hand, getting too permissive with security measures renders the entire point moot.

    A successful, secure user experience needs to weave tight security into a flow that makes sense, presented in a way that doesn’t detract from anything compelling about the software. 

    Improved Developer Upskilling

    Developers, of course, want to write secure code, but they often lack those skills or need a refresher course. Meaningful training too often gets overlooked as the day-to-day needs of organizations allow for little time to improve skills.

    In working with developers, we’ve found that about 75% prefer structured on-the-job learning instead of opening a manual. They would rather learn by doing and want training focused on practical applications, something that most current training programs are missing.

    Look for any and all opportunities to upskill your developers. They are on the front lines when it comes to stopping vulnerabilities. Provide them both the time and right-fit resources, understanding that these efforts will pay considerable dividends in the future.

    Government agencies, in particular, face inherent challenges in keeping their systems secure. They often must manage outdated systems with few financial resources and fight for top talent in an incredibly competitive market. There is no panacea for removing vulnerabilities, but taking a proactive and preventative approach that emphasizes the customer experience with highly skilled developers can help agencies take significant steps forward.

  • Site Reliability Engineering (SRE) Comes of Age in 2022

    Site Reliability Engineering (SRE) Comes of Age in 2022

    The site reliability engineer (SRE) role is still gathering steam across organizations. In January 2022, LinkedIn listed SRE as the 21st job with the highest global demand throughout the past five years. That’s pretty high for such a specific tech role. And, looking to the future, it appears the SRE practice will only continue to gain adoption as a method to support high availability, reliability and improved digital customer experiences. The SRE approach is also essential to meet service-level agreements (SLAs) and internal service-level objectives (SLOs).

    I recently met with Kurt Anderson, SRE architect, and Emily Arnott, content writer from Blameless to get their take on the top trends and predictions for the SRE practice in 2022. According to the Blameless team, 2022 will likely see increased adoption of the SRE role throughout companies and across internal departments.

    Just as manufacturing sets high standards for its quality assurance, digital applications now require the same high reliability to meet inflated user expectations. To address these new realities, SREs have their work cut out for them—they must confront how to unify disparate DevOps tools and must drill farther down to unearth specific user experience qualms—all without adding to alert fatigue.

    Increasing SRE Adoption

    As mentioned above, the SRE role has seen tremendous growth in recent years and doesn’t show signs of slowing. SRE as a practice was first popularized by Google in 2015. Today, they define it simply as “what happens when you ask a software engineer to solve an operational problem.” This equates to maintaining high levels of reliability for digital services by creating errors budgets, designing SLAs/SLOs and optimizing process automation over time.

    To Arnott, we’re still seeing SRE adoption take off at an exponential rate as more and more companies embrace Google’s SRE doctrine. “During the pandemic, more and more companies were forced to adopt a digital strategy. Reliability has to be fundamental to that strategy.” Arnott foresees SRE becoming a fruitful role at startups, which may initially have been intimidated by the prospect.

    “The practice of SRE is a scale issue,” Anderson explained. It can be difficult for time-pressed companies to enact an SRE program when their attention is already so divided. However, as new requirements force warp-speed innovation, we’re seeing greater DevOps adoption. And the SRE role, consequentially, is becoming more of an imperative.

    More Unification of Multi-Tool Condition

    Most DevOps professionals would agree—we live in a multi-tool world. For example, multi-cluster management concerns are bringing a plethora of new tools to the fold. And computing environments are just as diverse, often combining multiple clouds and composed of hybrid estates that house various clusters of microservices. Even within the same organizations, different teams may opt for differing DevOps tooling. Anderson believes that SREs can bring “more unification to a fractured DevOps adoption across a single company.”

    As companies adopt more software, there’s inevitably some degree of tool sprawl, Anderson said. For example, there may be competing methods to monitor the use of digital services. The platform team may be using Datadog, an app team may be using New Relic and another team may be using Prometheus. These tools don’t speak the same language and generate different logs, creating silos.

    For Arnott, the future involves accepting the innate complexity of the microservices era and using an agnostic layer that can receive data from anywhere to identify meaningful incidents.

    Observability Gets a Bigger UX Emphasis

    The SRE role is definitely a trend that has been growing and will continue to grow in importance, Anderson said. And as more organizations turn digital, it’s becoming necessary; with this shift comes enormous pressure to exceed user experience expectations. “Competition and people’s expectations are so high right now,” said Arnott. “If you are unreliable, it’s unacceptable these days.”

    Whereas DevOps focuses more on getting applications into production, SRE takes a more UX-focused approach. Take Netflix, for example, which has invested heavily in a core SRE team that ensures robust and reliable user-facing services. “A key underpinning to keeping our customers happy and streaming is a strong focus on reliability,” according to the Netflix Technology Blog.

    To cater to this new paradigm, teams will require a deeper understanding of observability based on particular cohorts of users, said Arnott. SREs require precise user experience contexts, such as an uptick of lags or increased error responses. But they also must discover the contributing factors behind these bugs. “SLOs and error budgets are like taking your temperature—they tell you if something is wrong. They don’t tell you why you have a fever.”

    SRE Takes Cues From Manufacturing

    As reliability becomes more and more central to a company’s brand presence, it’s only natural that something that important would be elevated into the executive suite, Anderson explained. As a reference example, he pointed to the fact that manufacturing industries often appoint a chief reliability officer. In traditional manufacturing, product lines undergo a statistical process control with rigorous testing to ensure quality. Analogous positions exist across industries, such as chief quality officers in financial services.

    The takeaway is that as reliability becomes more of defining competitive metric, tech companies may require a similarly high-level C-suite position to align on that idea and to direct teams to implement SRE practices. Of course, the necessity for such a title will entirely depend on organizational size and makeup.

    Greater Reliance on SLOs to Avoid Broken SLAs

    A service-level agreement (SLA) is typically a formal contract built around the reliability of a digital service with an external partner, which, if breached, may result in financial penalties or other forms of restitution. This agreement could exist between a software provider and an end user but is more strictly enforced in a B2B context.

    On the other hand, a service-level objective (SLO) is more of an internal target. SLOs are often set at a lower threshold than SLAs. For example, perhaps an SLA ensures a user login fails no more than 10 out of one million attempts, but the SLO is set at two out of one million.

    Setting internal SLOs helps keep engineers abreast of modest customer experience issues before they become a major incident that results in fines. “Some companies treat SLOs as just another alert; they should be representative of user experience,” said Anderson. It makes sense that as SRE initiatives begin to mature, companies will slowly start to adopt even more competitive goals to deliver superior user experiences and avoid unsatisfied partners.

    Final Thought: Don’t Play The Blame Game

    A big part of the SRE doctrine is the concept of blameless postmortems. Because when you’re in the middle of an incident, the worst thing to do is point fingers. “Blaming triggers a defense mechanism and when you’re in a defensive mode, you can’t respond well,” said Anderson.

    Instead, it’s better to keep an open mind when performing these retrospectives—accept that what occurred happened for a reason, and seek to discover that reason to make positive improvements. “What can we change at a systemic level to become more resilient?” inquires Arnott. “What is the origin of that mistake? What information was lacking? What communication should have happened to prevent this?”

    Typically, accidents don’t occur intentionally or due to incompetence but rather due to holes in the process. By not playing the blame game, companies are better positioned to fix issues as they progressively release new features. Then, hopefully, with the right SRE approach in place, teams can advance their digital services to meet the high stakes of today’s modern user experience expectations.

  • Embracing Security by Design in Development

    Embracing Security by Design in Development

    The number of data breaches publicly reported in 2021 far exceeded the total for 2020, making 2021 a record year. With cyberattacks on the rise and bad actors and ransomware gangs demanding millions in ransom, cybersecurity has taken on new urgency.

    In addition to more sophisticated hacking techniques, the rapid pace of tech adoption during the pandemic is another contributing factor fueling cybersecurity risks. A recent survey by Forrester shows 74% of companies attribute recent cyberattacks to vulnerabilities in technology put in place during the pandemic. As companies raced to enable remote work, develop new applications and roll out new consumer-facing digital solutions, cybercriminals saw new opportunities to identify vulnerabilities and to attack. 

    Cybersecurity threats can affect every business regardless of size and every individual, regardless of who they are or where they live. Even the most protected and advanced organizations are at risk: One of the world’s biggest cybersecurity companies recently fell victim to one of the largest breaches in history. It’s time for all companies to rethink their approach to boosting security in the software development process. 

    As a nearshore development partner for businesses around the world, we have embraced a ‘security by design’ mindset to keep our clients’ builds secure. To put security first and ensure it remains at the forefront of every engagement, we adopted a parallel build systems process to improve the integrity of the code we deliver. This also reduced the overall threat of potential attacks. How did we do this? There are three key components to developing and implementing a security-by-design mindset.

    Embedded Security Expertise

    It is critical that security experts become official members of every software development team. These specialists are there every step of the way from design to delivery, finding and fixing security flaws along the development journey. Instead of being brought in at the end of the process, they are deciding on new solutions and implementing protections in real-time alongside experts in design, user experience and coding. Each plays a role and works as an integrated member of the team providing advice and suggestions during Agile cycles and sprints. 

    Predictive Analytics

    A recent survey showed that 96% of third-party applications deployed in cloud infrastructure contain known vulnerabilities. That rising risk can make it possible for bad actors to infiltrate thousands of organizations. Threat hunting tools can spot, anticipate and predict vulnerabilities in software development. Tools can automatically scan code as it is written to vet and diagnose vulnerabilities. Our team scans code while in production and reports risks and vulnerabilities and then immediately consulting with the rest of the team to work on the next secure version. 

    Continuous Learning 

    Security is changing quickly, and it’s never been more critical to ensure developers have the skills necessary to defend and protect corporate infrastructure, applications and digital solutions. With the threat landscape constantly evolving, new skills and continuous learning are required to stay ahead of the latest threats and fraud techniques. Part of our training is focused on deploying white hats, or ethical hackers, to breach our development environments and the applications we deploy. These experts then set about identifying weaknesses and helping to improve security. They also take our training to the next level and push our experts to continually learn and educate themselves on the latest threats and solutions. By upgrading their skills, security practitioners can stay ahead of cybercriminals. 

    Every day, enterprises face thousands of attacks on their systems, and malware continues to grow in frequency, volume and complexity. These attacks are not just coming from criminals looking to make a buck; there are growing fears of nation-state attacks escalating. These are often seen as the more dangerous threats to businesses. The best defense against cyberthreats is a strong offense anchored by a security by design mindset.

     

  • CircleCI Adds Free Unlimited Access Tier to CI/CD Service

    CircleCI Adds Free Unlimited Access Tier to CI/CD Service

    CircleCI has added a free unlimited access tier to its continuous integration/continuous delivery (CI/CD) platform.

    Jim Rose, CircleCI CEO, said in contrast to other ‘freemium’ offerings, CircleCI’s free tier provides developers and DevOps teams with frictionless access to all the premium capabilities of the platform. Those capabilities include up to 6,000 build minutes per month, unlimited users, the ability to fine-tune pipelines using caching, concurrency, test splitting, security tools and health metrics.

    CircleCI claims more than 200,000 teams now employ its CI/CD platform. The freemium tier is intended to make it easier for a DevOps team to take advantage of a CI/CD platform as they begin an application development project, noted Rose. As that project evolves and matures, many of those teams will eventually require commercial support and other services provided by CircleCI, he added.

    The free tier of the CircleCI cloud service comes as many organizations attempt to accelerate the rate at which they can build and deploy applications. Digital business transformation initiatives, in particular, have become a much higher priority in the wake of the COVID-19 pandemic. A free tier of a CI/CD service is likely to encourage more experimentation simply because it reduces the level of overhead associated with setting up an application development environment.

    As the number of applications being developed continues to steadily increase, competition among CI/CD platform providers is becoming more intense as the number of organizations adopting DevOps best practices to accelerate application development increases. At the same time, more DevOps teams than ever are relying on cloud services to host CI/CD platforms in the wake of the COVID-19 pandemic.

    It’s still not clear whether DevOps teams will opt to rely on a proprietary platform versus an open source platform. While an open source platform prevents organizations from vendor lock-in, the ease of use of a cloud service may lessen those concerns as the cost of switching from one cloud service to another declines.

    One way or another, usage of CI/CD platforms will increase sharply in 2022. It’s not uncommon for different DevOps teams within the same organization to employ different CI/CD platforms despite efforts to encourage standardization. In the name of productivity, DevOps teams tend to exercise a fair amount of autonomy within many organizations.

    The biggest challenge, of course, will not necessarily be building applications but deploying them. Despite the availability of CI/CD platforms, the processes that most organizations rely on to deploy an application are still largely manual. In the age of the cloud, however, it should become easier to automate application delivery thanks to the APIs cloud service providers expose. In fact, 2022 may be the year that DevOps teams finally master CD. Providers of CI/CD platforms, of course, have a vested interest in making sure the full promise of an integrated CI/CD platform finally becomes an everyday DevOps reality.

  • Infrastructure Access Management a Growing DevOps Priority

    Infrastructure Access Management a Growing DevOps Priority

    Organizations plan to address access management over the next 12 months, as the need to secure and streamline infrastructure-wide access controls serves as a prerequisite to other initiatives, like zero-trust.

    This was one of the key findings of a survey of 600 DevOps professionals conducted by Pollfish and sponsored by strongDM. The report also found that legacy access processes created severe team inefficiencies.

    These inefficiencies require intensive time and resources to fix and block agile development practices: Nearly nine in 10 organizations surveyed said they required two or more employees to review and approve access requests and that those could take days or weeks to fulfill.

    The survey also indicated that organizations continue to use access management practices that are not secure and that make it difficult to track and audit users and permissions of critical business systems.

    Tim Prendergast, CEO of strongDM, said as more jobs become technical, there’s a bigger need to deliver access to more people–and that can have a severe impact on a company’s ability to remain secure. He explained that when 65% of organizations are reporting their teams used shared logins—and over 40% used shared SSH keys—there’s virtually no way for you to know who is in your infrastructure or the havoc they may be wreaking.

    “This makes it difficult to pinpoint any leakage or loss because you have 20 copies of your house key floating around,” he said. “It’s an example of the trade-off most organizations make when it comes to speed and ease of access versus ensuring that access is secure.”

    Survey respondents said their biggest challenges were the time required to request and grant access (52%) and the task of assigning, rotating and tracking credentials (51%).

    Hurry Up and Wait

    “Using current approaches to access means you’re hiring these high-paid, technical resources and telling them to hurry up and wait,” Prendergast said.

    Nearly half (47%) of respondents said they struggled with onboarding employees and contractors and Prendergast pointed out that one in four organizations said simply getting approval for access required a process that involved four people.

    “Think about that—in 25% of organizations, you have technical resources basically twiddling their thumbs while they wait to get access to this database or to that Kubernetes cluster,” he said. “Now multiply that by however many databases, servers, employees and third-party vendors that you have. And that’s not even counting when new technologies like Kubernetes are added to your infrastructure. Eventually, even just the frustration of your team as they wait for access becomes a liability.”

    2022: A Year of Convergence

    Prendergast predicted 2022 will see DevOps and security converge beyond what we’ve already seen with DevSecOps, where it has been heavily focused on shifting left and bringing security into the development cycle earlier.

    “This convergence will be marked by new workflows, technologies and solutions that not just improve security, but that also improve the development cycle,” he said. “One great example is optimizing infrastructure access—when done right, you can improve your security posture with zero-trust methodologies while also making it easier for DevOps teams to access systems quickly and easily.”

    He added that two of the biggest workforce dynamics facing zero-trust are remote work and the Great Resignation.

    “You used to have this environment where you’d have to be physically present or on the VPN to have access—remote work broke that,” he explained. “And now you also have this large number of employees leaving their jobs. Do you know what systems they had access to? How do you know if all of that access has been turned off? What happens if they were using shared credentials?”

    Prendergast said that’s why addressing access is critical to meeting this challenge and getting to modern security—if you don’t know who has access to what or what they can do in each system, you can never get to zero-trust.

    “Organizations need to find a way to understand the relationship between each technologist and each technology and then be able to track and audit those relationships,” he said. “Until you do that, you’ll have a really hard time getting to zero-trust. These are the table stakes for modern security.”

  • Survey Predicts Massive Migration to the Cloud

    Survey Predicts Massive Migration to the Cloud

    A global survey of 1,600 enterprise IT decision-makers found more than half are working for organizations that plan to eliminate the use of data centers over the next two years.

    The survey was conducted by Aryaka, a provider of a secure access service edge (SASE) platform, and found a quarter of the respondents have closed 25% to 50% of their office sites; 75% of respondents said at least a quarter of their employees will remain remote permanently post-pandemic. Just under a third (32%) expect at least half of their workforce would be permanently remote.

    Despite the apparent accelerated shift to the cloud, the report found a full three-quarters of respondents (75%) are projecting at least a 10% growth in IT spending, with a quarter expecting IT budgets to grow 25% or more. Nevertheless, more than a third (36%) report they have IT cost concerns.

    David Ginsburg, vice president of product and solutions for Aryaka, said the shift to the cloud in the wake of the COVID-19 pandemic is being driven mainly by digital business transformation initiatives that require applications be quickly built and managed by IT teams that are working from home themselves. With the pandemic entering the third year, a hybrid workforce that regularly shifts between home and the office is now permanent, he noted.

    Consequently, with more people working from home, nearly two-thirds of respondents (64%) said they will shift toward a SASE-based approach over the course of the coming year to provide secure access to cloud applications over a software-defined wide area network (SD-WAN). Over two-thirds of those respondents said they will opt for a managed SASE offering rather than build and maintain these platforms themselves.

    SASE was originally coined by Gartner to describe a cloud-delivered service that brought together networking and security offerings. Those offerings should include a firewall-as-a-service (FWaaS), secure web gateway (SWG), cloud access security broker (CASB) and zero-trust network access (ZTNA). In effect, it’s a secure software-defined wide-area network (SD-WAN). As organizations adopt SASE-based platforms and services, just under a third of respondents (61%) are recognizing that dynamic bandwidth reallocation will be a very important requirement as workers shift between the office and home.

    The transition to SASE involves setting a strategy (35%), phasing out of legacy virtual private networks (32%) and consolidating cloud security with zero-trust (29%). Top desired capabilities include SWG (47%), SD-WAN (36%) and FWaaS (28%). A full 41% reported that responsibility for networking and security decisions have now been consolidated into a single team. However, only slightly more than a third (34%) said security is a major priority.

    The implications of a shift to the cloud at this rate and level of scale are likely to have a profound impact on DevOps teams. While cloud infrastructure is designed to scale on demand, accessing applications across an SD-WAN can have a significant impact on application performance. The survey, however, finds only 29% of respondents are concerned about whether applications will perform properly. Nevertheless, well over two-thirds (69%) said there will be an increased focus on observability and control, while 42% noted identifying slow performance for remote and mobile users will be a key issue and 37% expected slow performance at the branch office to also be an issue. Lackluster application performance is a time sink, according to 42% of respondents.

    Naturally, many IT teams will add new tools and platforms to deploy and manage cloud applications. The Aryaka survey found that only slightly more than a quarter of respondents are concerned about the newness of the technology they might employ.

    The coming year is shaping up to be incredibly disruptive to the IT landscape. The challenge is making sure balance is maintained between cost, flexibility and application performance.

  • When to Use API Management and Service Mesh Together

    When to Use API Management and Service Mesh Together

    Though sometimes described as competing architectures, API management and service mesh have slightly different use cases and can actually work well together. Whereas API management provides the business logic for outside-facing traffic, a service mesh excels at handling intercommunication between microservices. An organization could certainly adopt both simultaneously across their projects. So, when does it make sense to use both API management and service mesh?

    I recently chatted with Mark Cheshire, director of product, Red Hat, to discuss the nuances between API management and service mesh. According to Cheshire, API management and service mesh can work quite well side-by-side for particular use cases. For example, a large organization using service mesh could benefit from applying API management that wraps microservices in a usable contract for internal departments. Or, API management could help a company expose specific APIs from the mesh to outside partners.

    When to Combine API Management with Service Mesh

    Say you already have service mesh—do you need API management, as well? Cheshire offered four questions to keep in mind that may influence your decision.

    1. Consider the number of connections and the number of consumers: Is it many-to-one or one-to-many?

    Within a monolithic application, communication is more centralized—there is more of a one-to-one relationship. However, when you break apart services into microservices and reuse them across an organization, a service may now have many consumers. This is a good indication you need an API management approach for the interface.

    “When environments get larger and larger, you can’t manage that as a flat mesh,” explained Cheshire. “You need some kind of organizational grouping by line-of-business or by the functions that you may have.”

    API management can create more formal interfaces between internal groups in a large organization that likely have little to no contact with one another. For example, perhaps the customer data team needs a formal method to connect with the sales organization. Or, maybe a security team supporting a login microservice needs to access financial details from an accounting division.

    2. What sort of access control and limiting does the system require?

    Consider what access control is necessary to secure your environment and avoid service disruption. A service mesh will typically use a zero-trust approach, applying mutual TLS over every ingress to each microservice. API management can also bring authentication controls and more advanced authorization and traffic mechanics.

    API management can provide a streamlined way to apply fine-grained controls for inter-domain traffic that follows the business logic. This helps assign access to specific resources to different requesting parties, such as read-only access for basic users or update access for admins. Amid increasing API attacks, setting fine-grained policies and permissions around your endpoints is becoming increasingly important to avoid data overexposure. This imperative increases as the binary between external and internal traffic fades with more public cloud use, remote work and third-party contractors.

    API gateways also place greater emphasis on communication rules and patterns. Rate limiting, for example, is very important to avoid collapsing entire networks, explained Cheshire. In addition to rate limiting, filtering, pagination and content negotiation are also standard API management capabilities that further optimize the exchange between the client and server.

    3. Do you require documentation for the services?

    In a monolithic setup, you likely have all developers sharing the same repository, explained Cheshire. This may still be true within an internal network of distributed microservices wherein each microservice is independent, yet developers can still access each other’s repositories. When you’re connecting services inside a domain, it’s often just the code itself (and perhaps some in-line commenting) that represents the contract between services.

    However, north-south traffic requires much more formalization, he said. Formal contracts are often necessary when one domain is communicating with another within the same company. In this scenario, there’s less tribal knowledge around how things work. API management is useful, in this case, to produce a developer portal with human-readable documentation that explains the methods, request types, URL structures and sample calls. This makes it much easier for someone without preexisting knowledge of the system to integrate with it.

    This formal contract is often generated from a specific file, such as OpenAPI Specification, which has emerged as industry-standard metadata for describing REST APIs. Groups can use OpenAPI to automatically generate documentation and even drive specification-first development. All in all, standardizing the way you document APIs and microservices can significantly improve the knowledge-sharing around how services connect.

    4. What is the nature of interactions?

    Another trait to keep in mind is the nature of interactions between services, Cheshire said. He divided systems into two large types: First is a graph model, in which any service can connect to any service. The second is a hierarchical model in which north-south traffic enables one service to have multiple consumers. A hierarchical model is necessary for productization and SaaS since it creates a single intercept point to the underlying resources. Maintaining hierarchy here is vital to retain simplicity, as you wouldn’t want the consumer to be able to hit all private microservices in a connected graph (unless that’s the intent!).

    API management thus enables the sharing of APIs on the mesh. “While they both use communication proxies, and while there are parallels in function, the differences in domain set them apart, and most companies will see significant benefits from using them together,” wrote Dino Chiesa and Greg Kuelgen on the Google Cloud blog.

    Better Together

    In summary, API management and service mesh go well together. “The two are complementary and can work together,” added William Morgan, CEO, Buoyant. Joaquim Moreno wrote, “they are not mutually exclusive; we should think about them as different layers in your infrastructure.”

    Specifically, combining the two is beneficial when:

    • Exposing and productizing APIs on the mesh
    • Formalizing inter-service communication in large corporate networks
    • Applying fine-grained access control; rate limiting for API-based microservices
    • Standardizing services with more formal documentation
    • Interaction is a more hierarchical communication model
    • Providing access to partners
    • When you need to externalize data to third-party plugins or integrations

    “The worlds of APIs and services mesh are becoming ever more closely connected,” said Cheshire. And API management won’t stop at REST—as developers adopt new integration styles like Kafka, GraphQL and asynchronous formats, the solutions will evolve. “It’s essentially a governance layer for all your integration points.”

    Large companies that seek to standardize inter-domain traffic within organizations will likely benefit from API management. But API management also offers the potential to productize internal infrastructure. Another benefit is that an API management gateway may also monitor and log requests, helping spot actors at the perimeter and keeping a helpful tally of incidents.

    Of course, adopting both API management and service mesh may be overkill for some scenarios. And, it’s good to remember that introducing additional layers inherently increases overall latency. It’s up to developers and architects to weigh the options and determine what’s appropriate for their unique environment. To enable this, a healthy culture of open communication is important to ensure teams are on a similar page across divisions, to avoid mismatched adoptions that only increase technical debt.

  • Zoom-Layoff CEO is Back | Bill Bans Targeted Ads | More FAA 5G Stupidity

    Zoom-Layoff CEO is Back | Bill Bans Targeted Ads | More FAA 5G Stupidity

    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: The return of the CEO who fired 900 staff on a Zoom call, Capitol Hill has a bill to kill ads, and a last-minute hiccup in the FAA/FCC 5G truce.

    1. Better.com CEO will Try to Do Better

    First up this week: Better.com, the DevOps-led mortgage lender, has its old CEO back. You probably remember Vishal Garg—he was the character who laid off 9% of his company on an open Zoom call.

    Analysis: Can leopards change their spots?

    Mr. Garg is being asked to help build “a respectful workplace.” But the famously combative CEO recently called investors “sewage,” threatened remaining employees with a “bloodbath,” and allegedly told a former business partner he would “burn him alive.”

    Riley de León: Better founder Vishal Garg … returns as CEO

    The move comes less than two months after Garg came under fire for laying off roughly 900 employees, or 9% of its workforce, via Zoom and subsequently stepped back at the request of Better’s board of directors. … According to an internal memo: … “CEO Vishal Garg has been taking a break from his full-time duties to reflect on his leadership, reconnect with the values that make Better great and work closely with an executive coach. … We are confident in Vishal and in the changes he is committed to making to provide the type of leadership, focus and vision that Better needs.”
    …
    The memo also reveals that board members Raj Date and Dinesh Chopra have resigned, though “not because of any disagreement with Better.” … Garg [had] cited market efficiency, performance and productivity as the reason behind the firings. [He later] accused the employees of “stealing” from their colleagues and customers by being unproductive and only working two hours a day.
    …
    In May, Better announced that it would go public. … Since then, multiple outlets have reported that Better has delayed its listing plans amid ongoing scrutiny.


    With a reminder, here’s Emma Goldberg:

    “If you’re on this call you are part of the unlucky group that is being laid off,” Mr. Garg told his workers [via Zoom]. “Your employment here is terminated effective immediately.”
    …
    Better.com has since conducted a “thorough, independent” review of its culture [and is] recruiting a new chairman for the board, a president and a chief human resources officer. … Some of the additional measures … include a training program on building “a respectful workplace” and a new ethics and compliance committee, reporting directly to the board.


    Don’t hold back—tell us how you really feel, @PCSAemilianus:

    What an utter pile of bull**** from this guy. He knew damn well what he was doing and didn’t care. You don’t “reflect” on that.


    2. Banning Surveillance Advertising Act

    Dems want to ban targeted ads. A new bill would outlaw the sort of adtech that Google and Meta/Facebook have turned into an art form. It would also put the kibosh on data brokers’ business models.

    Analysis: Expect Google and Facebook to fight like Spartans

    This will be an uphill battle. But it’s one that’s worth fighting: Surveillance capitalism has gotten normalized, but if consumers fully understood the extent of the privacy invasion, they’d rise up with flaming pitchforks in hand.

    Taylor Hatmaker: New privacy bill would put major limits on targeted advertising

    The Banning Surveillance Advertising Act, introduced by Reps. Anna Eshoo (D-CA) and Jan Schakowsky (D-IL) in the House and Cory Booker (D-NJ) in the Senate, would dramatically limit the ways that tech companies serve ads. … Targeting based on “protected class information, such as race, gender, and religion, and personal data purchased from data brokers” would be off-limits.
    …
    Sen. Booker called the targeted advertising model “predatory and invasive.” … Rep. Eshoo said, “This pernicious practice … fuels disinformation, discrimination, voter suppression, privacy abuses, and so many other harms.”
    …
    The bill would empower the FTC and state attorneys general to [levy] fines of up to $5,000 per incident for knowing violations.


    Trying to scan the bill, it’s Sam Biddle:

    A federal ban on surveillance advertising sounds like an extremely radical long shot. But I think the only people who would genuinely oppose it are the relatively small sliver of the population who make their money conducting the surveillance.
    …
    If it goes anywhere, get ready for a barrage of “this will literally murder small business owners” propaganda from FB/Google/et al. [It] is orders of magnitude more significant than any of the wishy washy We Can Reform Facebook! proposals you’ve seen in recent years, in terms of privacy and countering the power of big tech.


    Yay. Go GoTeam:

    Exactly! It’s the government’s job to secretly track us, not advertisers!(?)


    3. Last-Minute Hiccup in FAA/FCC 5G Truce

    A couple of weeks ago, I told you the FAA backed down in its opposition to 5G NR band 77. Well, a lot can happen in two weeks. It seems the airlines weren’t happy and demanded extra interference-mitigation from the mobile carriers at the last minute.

    Analysis: FAA vs. FCC: A plague on both their houses

    The various industries involved—and their regulatory agencies—have had years to sort this out. And it smells very much like the FAA is the one failing in its duty.

    Theo Leggett: Mobile firms agree another 5G delay at US airports

    The much-hyped expansion of 5G networks in the US has been chaotic, to say the least. The rollout has been delayed twice — and now AT&T and Verizon have bowed to intense pressure, agreeing to defer opening some parts of the network near airports.
    …
    There was clearly time to come up with a mitigation plan — and other countries have been able to do just that. The question is, why were US regulators, telecoms operators, airlines and airports apparently unable to come up with a workable solution?


    The FAA is “incompetent,” says David Von Drehle:

    5G — the long-promised next step in cellular technology. … It wasn’t a secret. … Yet it seems to have caught the FAA by surprise. … Various compromises and delays [have been] offered by the wireless industry — all met with last-minute panic-mongering by the FAA.
    …
    The FAA’s foot-dragging raises a red flag over the agency’s competence. … If a challenge as slow-moving and widely publicized as 5G can catch the FAA unprepared, it’s hard to be hopeful about smooth landings in … other areas … such as keeping up with pandemic health measures, battling unruly travelers and finding the next generation of pilots, flight attendants and air traffic controllers.


    Is there any doubt? No, opines @K0LWC:

    There is no doubt this is a colossal screw up by the FAA, and less so, the FCC. The 5G rollout and the bands being bid on were not a surprise.


    The Moral of the Story: The perfect is the enemy of the good.


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Jan Valečka (via Unsplash)

  • Drumroll, Please! The Winners of the 2021 DevOps Dozen² Awards Are …

    Drumroll, Please! The Winners of the 2021 DevOps Dozen² Awards Are …

    We are very proud to announce the winners of the DevOps Dozen² Awards for 2021. For the past seven years, the DevOps Dozen² Awards have recognized the stars of the DevOps community. Over the years, we have expanded the scope of the awards to honor a dozen DevOps tools and services as well as a dozen of the DevOps community’s best and brightest.

    Every year it gets harder to pick just one winner in each category. There are so many worthy contenders that even whittling down each category to six or seven finalists is difficult.

    Once the finalists are selected in each category, things become even more challenging. My fellow judges (Mitchell Ashley, Jayne Groll, Helen Beal and John Willis) and I try to look at the popular vote and use that to guide us. But we are also very familiar with the space and try to make these awards more than just a popularity contest.

    I know that might sound like a cliche, but it really is true—every one of the finalists in this year’s DevOps Dozen² Awards would have been a worthy recipient of the award in their category. Congratulations to all of them. You can see the complete list of finalists here.

    However, as they said in the movie Highlander, “There can be only one.” Without further ado, I am pleased to announce the 2021 DevOps Dozen² Awards honorees:

    DevOps Dozen Community Awards

    Best DevOps Industry Implementation

    City of Gainesville/Gainesville Regional Utilities

    Best DevOps Survey/Analysis/Research

    2021 State of DevOps Report

    Best DevOps Related Video Series (Video)

    DevOps Series (DevOps for IBM Z Media Center)

    Best DevOps Related Podcast of the Year (Audio Only)

    The POPcast, hosted by Dan “Pop” Papandrea

    Best DevOps Books / eBook of the Year

    A Beginner’s Guide to Observability by Splunk

    Top DevOps Evangelist

    Abel Wang

    Best DevOps Transformation (Non-Vendor)

    FedEx

    Best DevOps Virtual Event of the Year

    DevOps World 2021

    Most Innovative DevOps Open Source Project

    Prometheus

    DevOps Executive of the Year

    Shlomi Ben Haim, JFrog

    Best DevOps Presentation of the Year

    The Value of DevOps Transformation in the Digital Enterprise by Rosalind Radcliffe (IBM) and Mark Howell (Lloyds Banking Group)

    Best DevOps.com Article of the Year

    Measuring Value Streams by Analyzing Flow Metrics by Jeff Keyes

    DevOps Dozen Tools and Services Awards

    Best End to End DevOps Tool/Service

    GitLab 14

    Best DevOps Repo/GitOps Tool/Service

    Red Hat OpenShift GitOps

    Best CI/CD Tool

    CircleCI

    Best Value Stream Management Tool

    CloudBees Platform

    Best Observability Solution

    Honeycomb

    Best DevSecOps Solution

    JFrog XRay

    Best Testing Service/Tool

    Applitools

    Best Kubernetes Platform/Service

    SUSE Rancher 2.6

    Best Cloud Native Security Solution/Service

    Traceable AI

    Best DevOps for Mainframe Solution

    Zowe

    Best DevOps for DataOps/Database Solution

    The BMC AMI SQL Performance for Db2® Solution

    Best New DevOps Tool/Service Provider

    Nobl9

    Winners will receive both digital and physical trophies and badges celebrating their achievements.

    Many thanks to our panel of judges for making the hard calls and thank you to everyone who nominated candidates and cast votes. Thank you for supporting DevOps.com and the DevOps community.

    For more information, please visit the 2021 DevOps Dozen² Awards website and stay tuned for the 2022 DevOps Dozen Awards which will begin nominations in late August 2022.

  • Harness CD Platform Now Available via Source-Available License

    Harness CD Platform Now Available via Source-Available License

    Harness today announced a free community edition of its continuous delivery (CD) platform is now available under a source-available license rather than a more traditional open source license.

    Scott Sanchez, chief marketing officer for Harness, said the goal is to make CD as accessible to developers and DevOps teams as their current CI platform. Harness already makes an open source edition of its continuous integration (CI) platform available.

    The Harness CD platform is available under a Polyform Shield license that provides free access to the platform, including the right to use, modify and distribute it but not launch a competitive offering. A source-available license is an alternative to an open source license that allows an organization to potentially create a fork of the Harness CD that could, for example, be delivered as a cloud service. That specific issue has led to scenarios where vendors that create an open source project find themselves competing for revenue against a cloud service provider that is not necessarily as committed to contributing and maintaining the primary open source project. At this juncture, it’s not clear how many other vendors that make software available under an open source license might take a similar tack.

    While most organizations that embraced DevOps have been able to successfully implement a set of CI best practices, the number of organizations that have implemented CD is not nearly as high. One reason for that is automating deployments across platforms has never been especially easy. Each platform tends to be customized to the point where it is difficult to automate application deployments. In effect, each platform is its own unique type of “snowflake.”

    However, as the number of digital business transformation initiatives continues to steadily increase, the need to regularly update application experiences is going to require more organizations to implement a set of CD best practices. A source-available license should help increase the number of DevOps teams that can access and experiment with a CD platform, noted Sanchez. The challenge, of course, is that many of those applications are now based on microservices with components widely distributed across an IT environment.

    Historically, CI and CD have been synonymous when viewed within the context of a CI/CD platform. It’s not clear to what degree DevOps teams will look to better leverage the CI/CD platforms they already have in place rather than deploying a dedicated CD platform for IT operations teams and letting developers choose whatever CI platform they prefer. In general, a recent survey conducted by the Continuous Delivery Foundation found that 80% of respondents that work for companies with two or more employees are involved in DevOps to some degree.

    Regardless of approach, the coming year is shaping up to be one where many more organizations take DevOps initiatives to the next level. Arguably, as more organizations realize how dependent they are on software to differentiate themselves from rivals, the ability to deliver new application experiences has become critical. At the core of those efforts is a set of DevOps best practices that will ultimately determine just how competitive those organizations will be.