Tag: DevOps

  • Appstellar Is Now an AWS Consulting Partner!

    Appstellar is excited to announce that we have joined the Amazon Partner Network as an AWS Consulting Partner. With this partnership, we aim to continue building software products safely on the cloud!

    We’re excited to announce that we’re officially part of the Amazon Web Services Partner Network (APN)!

    Moreover, we at Appstellar, as a leading cloud service and DevOps service provider in Kosovo, are happy to share that we’re the first company founded and headquartered in the country to become an AWS Partner.

    APN is Amazon’s global community of partners who leverage AWS to build best-in-class software solutions. It consists of professional services organizations with a demonstrating track record of successfully delivering AWS solutions and an extensive pool of certified and experienced AWS technical consultants.

    As an AWS Partner, we support clients in maximizing the value of all that AWS offers and accelerating their journey to the cloud. APN enables us as a partner to provide innovative solutions, solve technical challenges, and deliver value to our and AWS’s mutual customers.

    Appstellar is currently in hyper-growth mode. In the past 6 months, we’ve grown our team by 122%! Moreover, we’ve signed multiple new client deals, expanded in new industries of operation (like fintech and healthtech), and also moved to new office spaces. In addition to our AWS partnership, Appstellar has also become a CNCF member and a Kubernetes Certified Service Provider. With these partnerships, we look forward to accelerating our growth even further and taking on projects we love to work on.

    Why work with an AWS Partner Company like Appstellar?

    Amazon Partner Network (APN) is uniquely positioned and powered to help customers take full advantage of AWS’s offering in their cloud journey. We as an AWS partner help our customers to grow and scale their businesses on what is known as one of the most advanced cloud ecosystems.

  • Jellyfish Launches Industry’s First Comparative Benchmarking Tool for Engineering Leaders

    Jellyfish Benchmarks Adds Anonymized Third-Party Performance Data; Allows Engineering Leaders to Set Productivity Goals Informed by Insights into Cross-Industry Standards of Excellence

    Boston, MA, May 18, 2022 — Jellyfish, the pioneer of Engineering Management Platforms (EMPs), today announced the launch of Jellyfish Benchmarks, a way to add context around engineering metrics and performance by introducing a method for comparison. With the industry’s only in-app benchmarking capability, Jellyfish customers can now understand how they stack up against peers on a percentile basis across numerous metrics on the organization, division, group or team level.  

    Despite having more access than ever to engineering data, the complex nature of modern software engineering means that strategic decisions can lack proper context. Engineering teams may be performing well historically, but without a threshold to compare against — one that represents the very best engineering team across different industries — engineering leaders lack insight into whether their decisions are enabling their organization to achieve elite performance. Jellyfish Benchmarks solve this problem by providing customers with means for comparison from anonymized cross-industry datasets.

    “At Jellyfish, our longstanding goal has been to support customers in building the highest-performing engineering teams possible,” said Andrew Lau, CEO of Jellyfish. “Today, we achieved yet another milestone by offering engineering leaders a trustworthy and expansive set of benchmarks derived from Jellyfish’s unrivaled customer base, providing the most comprehensive thresholds to measure against in the engineering industry.”

    Metrics-Based Engineering Management Is Here

    Engineering teams who opt in will have their data anonymized and added to the benchmarking Jellyfish customer pool. For every metric defined as important to an engineering organization, customers can access a visualization comparing their performance on a percentile basis for a given metric in comparison to their peers or against their own organization — truly an industry first. 

    Among the key metrics being announced with Jellyfish Benchmarks are those focused on allocation, delivery, productivity, collaboration – including key metrics within the DevOps methodology. Allocation benchmarks allow teams to understand how their resource investments compare to other engineering organizations. Delivery can be benchmarked using metrics such as cycle time, productivity using metrics like issues resolved, and collaboration using metrics such as PR reviews. New benchmarking capabilities also enable DevOps teams to track against the DORA metrics – including deployment frequency, lead time, mean time to recovery, and change failure rate.

    “At Acoustic, our number one goal is to do what we say we will do. We measure progress consistently across our engineering team,” said John Riewerts, senior vice president of engineering, Acoustic. “With Jellyfish’s Engineering Management Platform in place, we are now completing nearly all of our commitments in an agile culture. We’ve seen a 35% increase in our ability to do so. The Benchmarks feature gives us a consistent barometer to gauge our performance against teams in other industries, bringing a more game-like approach to our culture. This culture is massive from a productivity perspective, enabling us to meet marketers’ needs as they orchestrate journeys with highly personalized content with highly performant teams, and Jellyfish is critical to getting us to that point.” 

    “By offering the industry’s only in-app benchmarking, Jellyfish is empowering engineering leaders to use context driven by data to examine the efficacy of their engineering strategy and their team’s operations,” said Krishna Kannan, head of product at Jellyfish. “Jellyfish Benchmarks is available for every metric tracked across teams or the entire organization, helping customers understand how their company compares for the metrics that matter most to their engineering function.” 

    Jellyfish Benchmarks also provide data-driven insights with which to inform and influence non-engineering executives, and thus drive better strategic decisions and more closely align engineering with the wider business. The announcement of Jellyfish Benchmarks enhances the Jellyfish EMP’s current capabilities to measure engineering alignment against strategic business priorities and the performance and operations of engineering teams.

    To learn more about Jellyfish Benchmarks, watch the video demo or visit the Jellyfish website. 

    For press inquiries, please contact jellyfish@batemanagency.com.

    About Jellyfish
    Jellyfish is the pioneer Engineering Management Platform that enables engineering leaders to align engineering work with strategic business objectives. By analyzing engineering signals and contextual business data, Jellyfish provides complete visibility into engineering organizations, the work they do, and how they operate. Companies like Mastercard, Priceline, Zoominfo, and Pagerduty use Jellyfish to optimize the allocation of engineering resources to focus their teams on what matters most to the business. For more information, visit www.jellyfish.co

  • Making DevOps Smoother

    Making DevOps Smoother

    Being a DevOps developer isn’t just about technical expertise necessary to build a product. It is also about learning the operations that facilitate the entire process. That means working with a fast-paced, high-performance, cross-functional team using Agile methodologies. But because of these sometimes-conflicting demands, it can sometimes get rocky.

    Here, we’ll offer six tips for DevOps developers to ensure a smoother development process.

    Set Measurable Goals

    While working toward a specific goal, precision is paramount. Defining the problem accurately leads to a faster solution. For instance, “Configure deployment to a new region” is too vague compared to “Configure the deployment of all components of service X for North America.” The more specific aim of the latter makes it easier for the parties involved to identity the problem, make a plan and resolve the issue quickly.

    Most DevOps developers use the acronym SMART while setting goals in a sprint.

    1. Specific: Define exactly what needs to be done.
    2. Measurable: Highlight the parameters and values necessary to indicate completion.
    3. Achievable: Define how the task will be accomplished and decide who will be responsible for doing it.
    4. Realistic: How realistic is the goal based on the above details?
    5. Timely: Set the date and time when the task has to be completed.

    While setting goals for a particular sprint, keep the above five points in mind to make sure that the tasks are precisely defined.

    Document Everything

    Proper documentation during the entire course of development is valuable to everyone. In many cases, DevOps developers join the project after it has started, and having them review documentation created by other developers is the easiest way for them to get up to speed. Not only that, but documentation also helps with debugging, troubleshooting and guiding the clients.

    Documentation of the process is often seen as boring and a waste of time. However, thanks to online documentation tools, logging information has become a lot simpler. Using a document template with good formatting makes things easier down the line.

    Communicate and Collaborate

    Essentially, the efficiency of a DevOps development team boils down to how well they communicate and collaborate within the team and with the external stakeholders. Gaps in communication will slow down and possibly derail the entire development process. This is especially important as more and more teams are going remote and popping into your coworker’s physical workspace to ask a quick question is no longer possible.

    In a remote working environment, communication can be slower. Sending a text, waiting for a reply, scheduling a call, etc., adds a lot of steps to the process as opposed to simply pointing at a screen and asking a question. Although there are a lot of visual collaboration tools and more integrations for video conferencing tools, it is still not the same.

    Therefore, it is important to set firm communication and collaboration rules and make sure expectations are set from the beginning so that team members and stakeholders know what to expect. One of the easiest ways to do so is by having specific tools for specific channels of communication. Typically, there are three types of communication tools that are necessary:

    • Team communications: Messaging apps like Slack and Microsoft Teams.
    • Stakeholder communication: Basecamp, Workzone or regular email.
    • Video conferencing: Can be used for internal and external communication. For example, Zoom, Google Meet, etc.

    Automate Repetitive Tasks

    If there are certain recurring tasks that happen at a local level, you can use Bash or PowerShell. Bash is older and used by a lot of IT and DevOps teams. PowerShell, developed by Microsoft in 2006, is newer and has replaced the command shell in Windows environments.

    Although both Bash and PowerShell are cross-platform, generally Bash is preferred by Linux and macOS users whereas PowerShell is preferred by Windows users. Ultimately, it comes down to personal preference. No matter whether you choose Bash, PowerShell or a newer automation tool, automation will save a lot of crucial development time and remove toil from a developer’s workload.

    Choose the Right Tech Stack

    Every team is different in terms of their requirements and the tools they prefer. “DevOps tools” is a term that covers everything from server orchestration tools, cloud platforms, code management and many other categories. In simple terms, DevOps tools are instruments that make it easier to write, test, host and deploy code. There are many DevOps tools that a development team can choose from. Here are three of them which are worth considering.

    1. Git: Git is a version control and distributed source code management. It makes it easier for developers to collaborate, experiment and merge code on the main branch.
    2. Cloud IDEs: Fully hosted cloud integrated development environments (IDEs) protect your progress in case your local system fails. GitHub Codespace, Cloud9 and Glitch are the most popular ones.
    3. Containers: Containers simplify the build, test, stage and deploy pipelines. They can either be locally hosted or fully hosted on the cloud. Containers help to identify and fix issues before they are deployed.

    While choosing your tech stack it is important to keep the user experience and user interface, usability, scalability, available integrations and pricing in mind. Your tools should fit into your process, not the other way around.

    Value DevOps Culture

    The work culture is essential for the cumulative success of the entire DevOps team. The way the team interacts with each other defines the way they work. When a team is provided with a sufficient amount of freedom to make its own decisions, it will come up with innovative ways to make the overall process more efficient. Overcoming the divide between “dev” and “ops” in its own way will empower the team to do its best work.

    With that being said, remember that a culture is something that develops over time organically, not forced upon people.

    Wrapping Up

    Developing software while collaborating with IT operations doesn’t have to be hectic or frustrating. By following these simple tips you can improve your entire team’s productivity. We hope that this article has provided you with some insights that will help you smooth out any development hurdles.

    Happy developing!

  • Why Over-Permissive CI/CD Pipelines are an Unnecessary Evil

    Why Over-Permissive CI/CD Pipelines are an Unnecessary Evil

    Balancing the speed of innovation with security is an age-old problem in software development. This is no different in modern DevOps. Development teams want a frictionless path to deploy new code but often struggle with access permissions that are linked to services. The CI/CD pipeline makes it easier for developers to quickly introduce new features and updates, in an agile way. As application changes move through the CI/CD pipeline, automation can allow changes to happen very quickly, without creating downtime or delays on the customer side.

    Permissions of CI/CD Servers

    When it comes to the permissions of CI/CD servers, DevOps often don’t want to deny access. After all, the wide access permissions are part of allowing the speed of innovation, and development teams are regularly—and often understandably—cautious about putting least-privilege or other access rules in place.

    But there are some security risks to consider. Any developer being granted admin permissions to deploy new code is open to vulnerabilities, weaknesses and misconfigurations. Cloud sprawl has created a lack of visibility into whether or not the infrastructure is properly set up and connected with logging tools. How does the development team know if things are getting properly patched?

    The balance is extremely sensitive. DevOps need the speed of change and the ability to innovate freely, but security teams can’t handle the growing risk. Something has to change that can allow security to shift left and get involved earlier in the CI/CD pipelines rather than getting in the way.

    Reducing the Risk Without Impacting Innovation

    Here are some suggestions for accelerating the speed of innovation while maintaining a healthy security posture:

    • Map threats and secure connections. Conduct a threat modeling exercise to map threats to the pipeline. Remember that every connection to the CI/CD pipeline is a potential point of compromise. Regularly patch and scan all services that connect to the pipeline and block the devices if they fail to meet security policy requirements.
    • Learn to love logs. When a security issue arises in production, developers, IT engineers and security engineers need to react quickly and efficiently to solve the problem. Logging is critical for enabling fast and coordinated responses. Waiting on manual sharing of sensitive data can slow down reaction times. But when every stakeholder can get the data they need from logs, access to information is no longer the weakest link in the security incident remediation process.
    • Tighten access control and enforce strong admin permissions. Be specific about who has access to which data. Clear and enforced separation of duties should ensure no one person or account can access more than necessary in the continuous software delivery pipeline. Improperly credentialed users or bad actors can’t establish control over the entire pipeline and mess with the code or processes. Moreover, they won’t easily be able to penetrate deeper into other corporate systems and data.
    • Leverage flags to manage risks. Developers often use feature flags (or feature toggles) to add new features to applications while mitigating the risk that those features will introduce performance or stability issues. Although most developers likely don’t think of feature flags as a security tool, they can be used for that purpose, too. New features are prime vectors for security vulnerabilities, especially if developers haven’t thoroughly tested them yet.

    Many security teams do not realize that just because their network is private, they’re still sharing pipelines with third parties, including anyone from maintenance to the team deploying your mobile app. By embracing these tools, developers can shift left, shoring up defenses early in the process, without adding a blocker to the pace of innovation coming from DevOps CI/CD pipelines.

  • The World’s Most Advanced Embedded Security Solution

    San Francisco, CA, Rome, ITALY, May 16, 2022 — Exein is an innovative company and leading provider of Embedded Security Solutions for IoT Devices. With proprietary AI algorithms, their product detects and mitigates cyber threats to protect your customers and devices from malicious attacks.

    Pulsar is Exein’s modular agent framework that provides reactive defence capabilities with low runtime costs while being optimised for performance on edge computing systems. It has been developed using state-of-the-art practices in Rust, a language which was specifically developed to keep up with today’s pace of innovation.

    This revolutionary idea has an immense amount of room for growth. If you believe McKinsey, there will be 43 billion IoT-connected devices in the next five years – which is over 10 times higher than now!

    “It’s not just about thwarting ransom threats,” says their CEO, Gianni Cuozzo. “The exploitation of embedded devices can affect our safety too. Aviation, automobiles and home safety systems can all be targeted. Pulsar is a world-changing product that represents an entirely new way of approaching IoT security.”

    Their organisation was created to build a new ecosystem for embedded security, focused on technologies that bridge between mobile networks and industrial equipment. 

    Their team of engineers and researchers works towards creating malware detection systems so that they can keep up with today’s challenges – where every company must stay safe from external threats as well as internal ones. 

    One example of such an external threat is protection against advanced cyber-attacks often seen in firms producing satellite communications equipment. Although there are many methods used by other agencies – such as PKI or Firewalls – which allow these firms to guard themselves against hackers intent on hijacking an IP address, they believe Pulsar can do it more efficiently while still preserving optimum responsiveness. 

    In addition to developing original technologies aimed at securing companies against vulnerabilities they are also actively committed to training people in cybersecurity techniques through their community.

    For more information: https://www.exein.io 

  • EP 28: Hyperscale DevOps

    EP 28: Hyperscale DevOps

    Hyperscale DevOps: How Do You Get There? Hyperscaling DevOps is the key to a successful digital transformation. Hyperscaling is a whole new game and it demands a new level of coordination, processes, tools and mindset. Is hyperscaling DevOps an attainable goal for your organization? Mitch Ashley is joined by Tracy Ragan (DeployHub), Parag Doshi (Tricentis) and Larry Maccherone (Contrast Security) as they discuss DevOps at hyperscale, enterprise scale versus startup scale, how to set up a hyperscale environment and how to test at hyperscale.

  • Update Those Ops Tools, Too

    Update Those Ops Tools, Too

    We’re all pretty well settled on the idea that the rate of change in IT has been on the increase over time. From the advent of VMs to Agile to DevOps to containers, the movement has been faster—and the same is true for internal development.

    I’m going to approach this topic from three perspectives instead of my usual two. Kind of like breaking the fourth wall in cinema. We’ll discuss this movement just a bit from the perspectives of my two preferred bits, DevOps and DevOps. But for this blog, we’ll also mention DevOps—the infrastructure, tools and processes that enable the other two.

    For DevOps, languages—both updates to those currently in use and the addition of new ones—bring with them a nearly automatic update to tools used. Favorite libraries/modules, IDEs, build tools—these are all looked at and updated more frequently today than at any point in history, by my estimation. For teams that do not change languages or libraries much, source code analysis (SCA) scanning is increasingly helping to take a closer look at all those included tools and filter them based upon impact (normally security impact, but other impacts on occasion, too—like project activity and stability).

    For DevOps, the toolchain is still new enough that evolution is causing regular change, and that change is bringing with it new tools and utilities to solve the problems of this existing infrastructure. In fact, I’ve long thought the DevOps part needed a bit of a cooldown on the change and new tools/utilities front, personally.

    And finally, DevOps has gone a bit sideways in this regard. Every person—whether you call them ops, admin or DevOps—responsible for troubleshooting machines and apps has a collection of tools. But the divergence of platforms has created a divergence of tools. It is possible to work without a dedicated set of tools—and, indeed, many DevOps engineers do. Others have a folder. Meanwhile, there is another dedicated set of DevOps engineers that have a PCMCIA or USB full of useful tools that is always with them. Some have both. Of course, what tools are included in all of this varies widely also. It is an interesting artifact of our growth in IT that developers tend to share or borrow the best libraries/modules/APIs across an organization, but DevOps is more independent. As long as DevOps team members are getting the job done, no one is all that worried about which tools they used to troubleshoot. They do tend to share if asked, but with little physical evidence of what tools they used, it doesn’t come up often.

    So, what am I getting at? Look for ways to enable DevOps tool sharing on an ongoing (or at least regular) basis. An internal social media channel dedicated to the vendor your teams use to communicate, brown bags, a maintained rating system “Why I think fdisk rocks” type of thing, etc. The more power there is at the fingertips of every DevOps member you have, the better. Given our history, building an “approved” list is likely a bad idea, but having that central communication location that security can also peruse to look for red flags is not a bad idea. Of course, they are likely too busy, but worst case, such conversations can help in forensic analysis later. Not being cynical, just living IT in the 21st century.

    And keep kicking it. More and better tools will help keep all those sweet apps and servers clipping along, so there is really only upside here. Give your teams the tools and revel in your considerable uptime.

  • Jamstack Will Revolutionize How Websites Are Built

    Jamstack Will Revolutionize How Websites Are Built

    Today, every organization wants a website that loads quickly and looks sharp. The reasons go much deeper than cosmetic motivations, though—even a slight delay in loading can cause users to exit a page prematurely and site performance plays an important role in search engine rankings. Meanwhile, threats like ransomware and phishing are everywhere and are constantly evolving, requiring organizations to look for more ways to improve site security and protect user data from bad actors. Then, of course, there’s the need to quickly and easily scale websites to meet sudden spikes in demand. The need to adapt quickly has become especially apparent over the last two years as we have come to rely on the internet in new and profound ways compared to pre-pandemic times. Fortunately, a relatively new but popular approach to web development—Jamstack—is taking websites to a nearly infinite level of scalability and performance, serving up only what you need, when you need it. To understand the value that Jamstack brings today, it’s helpful to take a look at how we got here. 

    Throughout the history of the internet, web and database servers were the primary infrastructure for site hosting. When websites got more complicated, another layer, called the application tier, would take on more complex aspects of the site (like an API, for example). As traffic increased, web servers were scaled out to add capacity with the help of load balancers. Scaling in this manner wasn’t always easy or cost-effective, given how unpredictable consumer demand and spikes in traffic often are. Later, content delivery networks (CDNs) came into the picture, taking a load off web servers by pushing static content to the edge. But, for most traffic, the origin servers would still have to be ready to serve site visitors. In this approach, website development and management were often costly and difficult to scale, and sites faced constant security risks. 

    Enter Jamstack. With Jamstack, all site content sits on a CDN, ready to be served. Web pages are pre-rendered instead of being rendered in real-time (as was the case in pre-Jamstack days). As such, content is closer to the end user, pages load faster and sites can easily scale up or down to handle unexpected shifts in traffic.

    Jamstack represents an exciting and fundamental shift in how we have traditionally approached web development—one that is inclusive of the needs for performance, security, availability and scalability and at a much lower cost to the developer. It’s no surprise that Jamstack has taken the web development world by storm over the last couple of years; in 2020, the number of sites developed with Jamstack jumped 85% from the year prior. Here, I’ll share some basic tips for getting the most out of Jamstack.

    Adding Dynamic Features to Static Sites

    Jamstack starts with the idea of a static site—pre-building as much of a site as is practical—and incorporates dynamic elements to achieve fast websites with fewer attack vectors. The term, which was coined in 2015 as JAMstack, derives from: 

    • J = JavaScript, the website’s programming language 
    • A = APIs, which enable dynamic content on an otherwise static page
    • M = Markup, which is the HTML and CSS code that provides formatting instructions to the browser 

    By combining these three elements, Jamstack allows developers to quickly create and maintain websites that can be served efficiently to users. A static site renders well for mobile, web and video while relying on APIs for dynamic features. High page speed is achievable by pre-building as much of a site as possible and then using a CDN to deliver the page to users around the world. When a user visits a website, they see a pre-rendered page delivered by the CDN with no dedicated servers needed.

    Notably, the page’s static nature does not require the content to be static. Leveraging third-party APIs can enable dynamic content such as search, payment processing and real-time data. This modular approach allows for flexibility and avoids vendor lock-in—swapping out different APIs as technology changes and new tools become available is easy. The ability to integrate with serverless functions also lends itself to Jamstack sites becoming more dynamic.

    Without the need for web application servers and database servers, Jamstack pages scale well as visitors increase, improving both the experience of the visitor and the organization’s bottom line.

    In essence, a Jamstack site has no backend that needs to be managed by a developer. The static nature of the page means there is no link between the website and a database, which reduces the security attack surface. Since all site elements are delivered from the CDN or an API, potential attackers aren’t able to hack web application servers or database servers.

    When an organization creates a website with this approach, there are no servers to maintain and no staging environments to create, so there is less of a need for complex DevOps resources. Jamstack’s simplicity means there are fewer moving parts than in a traditional site and less room for error. Because of this decoupling between the frontend and backend, Jamstack sites are faster to launch and more reliable.

    Another advantage of the static setup is that reverting to an earlier version of a page is simple. This is possible through the concept of atomic deploys, where the entire site is updated at once, creating a new version. With Jamstack, developers have more freedom to experiment and avoid the tiring trial and error of traditional sites—if something does not render as intended, switching the entire site back to a previous version is painless. 

    Assembling a Jamstack Toolkit

    Jamstack’s tools, processes, and best practices are evolving rapidly, and an important part of diving in is remaining open to experimentation and tracking emerging developments. Getting started is simple since Jamstack integrates with existing workflows and many organizations have established relationships with vendors already in place for key technologies, speeding up the decision-making process. These technologies include:

    • CDN: To deliver pages from locations close to users—a requirement for achieving fast performance. 
    • Static site generator (SSG): To generate the site using raw data and templates—automating the process of coding pages and ensuring they are pre-built and ready for users.
    • Content management system (CMS): To act as a content repository. A CMS for a Jamstack website is described as “headless,” which means that content is stored outside of the codebase and delivered via APIs for seamless display across different devices.

    Expanding the Value of Jamstack

    We are still in the early years of Jamstack’s maturation, and not all deployments are equally effective. For example, some Jamstack platforms are hosted out of centralized data centers coupled with a CDN, which slows performance relative to delivering sites directly from the edge. Some Jamstack hosts also charge more to add developer seats, which discourages collaboration among large teams and can result in unpredictable pricing. 

    Regardless, Jamstack is one of the best technological solutions to come to developers in recent years and one which will surely influence the future of web development. Not only does it make websites faster, more secure, and easier to scale, but it builds on many of the tools developers already know and love—empowering them to achieve their maximum productivity.

  • DevSecOps: Realities of Policy Management

    DevSecOps: Realities of Policy Management

    Policy management is essential to scale cloud environments and is key to secure DevOps practices. It enables organizations to manage policies put in place that secure the cloud environment, ensure Kubernetes configurations are secure and enable the continuous monitoring of a company’s overall security posture. 

     As businesses migrate workloads across multi-cloud architectures to achieve the agility and scalability needed to keep up with the pace of digital transformation, the growing demands placed upon developers often leave a gap that exposes potential threats and risks in the configuration settings, making security an even greater focus in DevOps. In fact, IDC’s 2020 survey found that 67% of breaches in the cloud are caused by misconfigured applications or infrastructure, including some of the industry’s largest breaches like Marriott’s second breach.

     To add to this, the first State of Policy Management report by Nirmata and the creators of the CNCF project Kyverno revealed that nearly 50% of users in cloud-native environments have now adopted some type of policy management solution. This tipping point of mainstream adoption across production cloud-native environments is making it critically important for DevOps teams to look at their practices and simplify and operationalize policy management across their Kubernetes stack by eliminating vulnerabilities through built-in, curated policies, without the barrier of learning complex policy languages. But this widespread adoption also acknowledges that organizations are finally realizing the need to put attention, investment and innovation into addressing security and compliance gaps as they adopt Kubernetes through proper DevSecOps practices and tools so applications being built can empower businesses.

    To confidently build cloud applications in Kubernetes, DevSecOps teams need to accept these DevSecOps realities and apply policy management effectively. 

     Customization Creates Security Risks

    Kubernetes can be highly customized, but DevSecOps teams need visibility into what’s happening in each cluster as organizations scale to ensure application reliability and security. Exploits on containers—including malware installation, cryptomining, host access and privilege escalation—offer opportunities for more security vulnerabilities. They can exist in images, production-accessible container registries, failed builds and third-party admission controllers in Kubernetes clusters.

    To address these risks in applications running on Kubernetes, it’s important to protect your environment with three A’s: Authentication, authorization and admission. This should be done at the cluster layer which enables secure access to authenticated entities that are authorized to perform certain actions. One way to accomplish this is through policy management. In fact, according to the State of Policy Management report, the top use case for policy management is for Kubernetes admission control (31%). When a request is authorized, having a policy in place ensures the request goes through another set of filters. For example, an authorized request may be rejected by an admission controller due to quotas or due to other higher-priority requests. In addition to validation, admission webhooks can also mutate incoming requests as a way of processing request objects for use before reaching the Kubernetes API server. 

    Configuration Issues

    Container images, namespaces, runtime privileges, persistent storage and control plane, together with network policies that are not compatible with best practices, are a source of misconfiguration and risk exposures. It’s this potential for greater risk exposures that have led configuration management to be a key driver of policy management adoption. In the Nirmata State of Policy Management report, it ranked third in security tools that are adopted today and fourth for the organization’s plans for future adoption.

    There are several ways to define security policies to protect cloud environments. Policies can be used for auditing purposes, to reject pod creation or to mutate the pod and limit what it can do. By default, pods can receive traffic from any source and send traffic to any destination. Network policies allow you to limit the ingress and egress access for your pods. The network policy typically translates to firewall rules.

    Lack of Adequate Authorization 

    Cloud authentication allows authorized users to securely access information stored in the cloud with authentication provided through cloud-based services. In The State of Policy Management report, key findings revealed that more than 24% of respondents today are using tools like policy management to authenticate users accessing applications. With data theft one of the fastest-growing and most expensive cybercrimes, the ability to process information and have strong authorization measures needs to be part of DevSecOps best practices.  

    In Kubernetes environments, as a user request is authenticated, it goes through an authorization workflow that decides if the request should be granted. It evaluates the request attributes against all policies and allows or denies the request. The main authorization mechanism is role-based access control (RBAC). Each authenticated request has an HTTP verb like GET, POST or DELETE, and authenticated entities have a role that allows or denies the request. Other authorization mechanisms include attribute-based access control (ABAC), node authorization and webhook mode.

    As the trend of moving security further to the left in the application life cycle accelerates, developers are being required to take active responsibility for it, which creates a higher desire for automation. The rapid releases can expose applications to many vulnerabilities, raising the risk of a breach.  With DevSecOps, organizations can transform the development pipeline by shifting security and compliance to the left, enabling developers to check the code before every commit. In doing so, security and compliance vulnerabilities can be identified and fixed in development, saving the organization from high costs and negative publicity from potential breaches. 

    There’s no doubt that Kubernetes is complex and challenging to adopt. On top of this, the development landscape is flooded with tools and more demands are being placed on engineers.  These shifts are changing the traditional role of a developer, leaving a gap for organizations to address to get the most out of DevOps. But by taking a secure, continuous, iterative approach that also includes policy management, companies can reduce the risk and exposure of their cloud environments. The more mature an organization’s DevOps practices are, then generally, the stronger the security and compliance practices are—they grow in relation to each other. The most innovative companies accept policy management in DevSecOps as a necessity of development and adopt some level of policy management best practices. With the right implementation tools like policy management and security and compliance best practices, organizations can remain efficient in agile and DevOps while adhering to critical go-live deadlines—which can’t be missed in this fast-paced business environment. 

  • Domino 5.2 Accelerates Model Velocity and Enables More Efficient Data Science Across the MLOps Lifecycle

    New capabilities accelerate data preparation, model development, and enable model deployment in Snowflake’s Data Cloud

    New York City, NY, May 5, 2022 — Today at the Rev 3 conference, Domino Data Lab, provider of the leading Enterprise MLOps platform trusted by over 20% of the Fortune 100, announced its latest platform, Domino 5.2. This powerful release continues Domino’s progress towards helping enterprises become model-driven by allowing data science and IT teams to develop and deploy more models faster, slash data and infrastructure complexity and costs, and extend autonomous model performance monitoring to Snowflake’s Data Cloud. 

    Throughout the lifecycle of a model, data science teams must contend with non-data science tasks, workarounds caused by inflexible tools and complex processes, as well as rising tensions with IT. Domino 5.2 helps reduce this complexity and alleviate friction with IT over costs — allowing teams to accelerate the MLOps lifecycle.

    New capabilities will recommend the optimal size for a development environment, thereby improving the model development experience for data science teams and delighting IT with reduced cloud storage costs. Integrated workflows in Domino 5.2 automate model deployment to Snowflake’s Data Cloud and enable the power of in-database computation, as well as model monitoring and continuous identification of new production data to update data drift and model quality calculations that drive faster and better business decisions.

    “Data science teams make their biggest impact on business and humanity when they focus on building, deploying and improving models on their own terms, without fear of vendor lock-in, rising costs or risk,” said Nick Elprin, CEO and co-founder of Domino Data Lab. “Domino 5.2 enables our customers to maximize model velocity across the MLOps lifecycle using powerful tools of their choice and scalable infrastructure like the Snowflake Data Cloud.”

    “Our teams demanded a machine learning platform that would give us the freedom to leverage a variety of data platforms while managing cost and risk,” said Stig Pedersen, head of machine learning at Topdanmark. “Domino’s Snowflake Data Cloud integration helps our team focus on data science, not complicated data regulatory requirements, with improved efficiencies, such as rapidly discovering model drift to minimize the potential business impact of suboptimal predictions.”

    With powerful capabilities across each critical stage of the MLOps lifecycle, this release solidifies Domino’s position as the most open and flexible Enterprise MLOps platform in the industry:

    Smarter model development with a new data preparation and visualization option, and IntelliSize for development environments

    It is widely acknowledged that data scientists spend significant time building, preparing, and cleansing data before modeling. With Domino 5.2, they can now overcome this hurdle using a native SQL-based environment based on Apache Superset. This fully integrated option for data visualization delivers to teams a deeper understanding of the breadth and quality of their data to be modeled.

    As data scientists use more software and compute, IT needs to manage more cost and operational burden. Domino’s Durable Workspace development environments are now smarter and more efficient with a new IntelliSize capability that will recommend the optimal size for an environment. For data science teams, this means less complexity and more productivity. For IT, eliminating excess workspace capacity and automatically deleting abandoned workspaces can significantly reduce monthly cloud storage costs. 

    Flexible model deployment using Snowflake for in-database computation

    Orchestrating the movement of data takes custom development work and forces manual workarounds that consume valuable time for data scientists and ML engineers, and introduce unnecessary risk. Domino has partnered with Snowflake to integrate end-to-end workflows across the MLOps lifecycle. Domino 5.2 combines the flexibility of model building in Domino with the scalability and power of Snowflake’s platform for in-database computation. Customers can train models in-database using Snowflake’s Snowpark, then deploy those models directly from Domino to the Snowflake Data Cloud for in-database scoring – simplifying enterprise infrastructure with a common data and deployment platform across IT and data science teams.

    Streamlined real-time model monitoring in Snowflake Data Cloud Environments

    Models most often decay as soon as they are put into production due to changes in business conditions, customer preferences, and other factors. Without proactive monitoring for data drift and accuracy, companies risk making bad business decisions based on outdated models. 

    With Domino 5.2, data science teams can now automatically set up prediction data capture pipelines and monitoring for models deployed to the Snowflake Data Cloud. Domino will also now continuously update data drift and model quality calculations to drive increased model accuracy and ultimately better business decisions.

    Domino 5.2 will be generally available to customers in June 2022.

    Additional Resources

    About Domino Data Lab 

    Domino Data Lab powers model-driven businesses with its leading Enterprise MLOps platform trusted by over 20% of the Fortune 100. Domino accelerates the development and deployment of data science work while increasing collaboration and governance. With Domino, enterprises worldwide can develop better medicines, grow more productive crops, and build better cars, and much more. Founded in 2013, Domino is backed by Coatue Management, Great Hill Partners, Highland Capital, NVIDIA, Sequoia Capital and other leading investors. For more information, visit www.dominodatalab.com