Category: DevOps Toolbox

  • Progress Expands Chef Automation Portfolio

    Progress Expands Chef Automation Portfolio

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

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

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

    Chef

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

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

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

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

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

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

  • CircleCI Bets on Webhooks to Streamline DevOps Integrations

    CircleCI Bets on Webhooks to Streamline DevOps Integrations

    CircleCI today announced CircleCI webhooks, a feature that enables software engineering teams to build integrations that react to CircleCI job and workflow status notifications in near-real-time.

    Tom Trahan, vice president of business development at CircleCI, said this latest iteration of the company’s implementation of webhooks, which send messages any time an event occurs, will become the foundation upon which CircleCI will expand the ecosystem surrounding its continuous integration/continuous delivery (CI/CD) platform.

    For example, the CircleCI platform can now employ webhooks to integrate with a CI visibility tool from Datadog that can now be used to surface CicleCI metrics. Sumo Logic is similarly employing webhooks to enable its Continuous Intelligence observability platform to track events on the CircleCI platform. Those capabilities are now available via the software-as-a-service (SaaS) edition of the CircleCI platform.

    Trahan said the primary goal is to reduce the amount of friction within DevOps workflows that span multiple platforms by increasing the level of orchestration DevOps teams can take advantage of without having to create and maintain integrations using low-level application programming interfaces (APIs).

    Webhooks make it possible to streamline developer workflows while also increasing overall engineering velocity, he added. In addition, it should also become simpler for DevOps teams to triangulate events in a way that results in incidents being resolved faster, noted Trahan.

    CircleCI is relying on webhooks to strengthen its case for a best-of-breed approach to DevOps that enables organizations to mix and match tools as they best see fit rather than getting locked into a single integrated DevOps platform. The best-of-breed approach often makes it simpler to take advantage of new tools as they become available. The downside is the level of integration that DevOps teams need to maintain after they integrate all the tools that make up a DevOps workflow.

    It’s not clear what impact relying on webhooks to share messages in real-time about events as they occur across multiple platforms will have on integrations. However, any effort to streamline DevOps environments without requiring DevOps teams to abandon one tool for another is likely to be well-received. After all, every minute spent managing a DevOps platform means much less time that can be applied to building and deploying applications.

    It will be up to each DevOps team to decide to what degree a best-of-breed approach to DevOps suits their organization. As more organizations realize how dependent they have become on software to, for example, drive digital business transformation initiatives, many IT leaders are making a case to standardize DevOps platforms across their organization. Achieving that goal, however, may be difficult given all the various departments within an enterprise that have already adopted a wide range of tools and platforms.

    In the meantime, the focus on developer and engineering productivity will only increase as organizations look for ways to further accelerate application development and deployment at a time when software updates can now have a profound impact on profits and revenue. In fact, a delay to one software project can have a cascading impact on a wide range of initiatives that can’t go forward because of their dependency on a delayed project. Given the impact all those delays might have on revenue, the tolerance organizations have for delays to software development projects is understandably lessening by the day.

  • CNCF Advances OpenTelemetry Initiative

    CNCF Advances OpenTelemetry Initiative

    The Technical Oversight Committee (TOC) of the Cloud Native Computing Foundation (CNCF) has voted to accept OpenTelemetry as an incubating project as part of an ongoing effort to simplify instrumentation of software using open source agent software.

    OpenTelemetry is a collection of tools, application programming interfaces (APIs) and software development kits (SDKs) that can be employed to collect metrics, logs and traces that make it simpler to determine the root cause of an application issue.

    At its core, OpenTelemetry is based on an OpenTelemetry Protocol (OTLP) specification that describes the encoding, transport and delivery mechanism of telemetry data gathered from sources, intermediate nodes and backend platforms. An OpenTelemetry Collector provides a vendor-agnostic implementation for receiving, processing and exporting telemetry data. APIs and SDKs that make it possible to instrument applications are available for 11 different programming languages.

    Previously a sandbox-level project within the CNCF, the next step would be for OpenTelemetry to become a graduated level project alongside other open source offerings such as Kubernetes and Prometheus, a platform used to monitor IT environments.

    The OpenTelemetry project was created via the merger of the OpenCensus and OpenTracing projects in May 2019. Since then more than 500 developers from 220 companies, including Amazon, Dynatrace, Google, Honeycomb, Lightstep, Microsoft, Splunk and Uber have contributed to the project.

    Most providers of observability platforms have at least signaled their intent to support OpenTelemetry as an alternative to proprietary agent software they had previously created to collect metrics, logs and traces.

    Ben Sigelman, one of the co-creators of both OpenTracing and OpenTelemetry and CEO of Lightstep, said different elements of the OpenTelemetry project are at varying stages of maturity. As such, support for the elements of the project are being added to platforms depending on the degree to which a vendor has confidence in, for example, the ability of OpenTelemetry agent software to collect logs.

    Liz Fong-Jones, principal developer advocate for Honeycomb.io, a provider of an observability platform, said that, in time, most observability platforms will support all the elements of the OpenTelemetry initiative to reduce their own engineering and support costs. In time, those savings will be passed on to organizations that will be able to instrument applications more affordably, she noted.

    It may take a while longer for OpenTelemetry to be widely employed, but the faster organizations transition to microservices-based applications the more pressing the need for open source telemetry software becomes. The dependencies that exist between all the microservices that make up multiple applications will be unmanageable without some form of telemetry. The challenge organizations face is finding an affordable way to instrument all those microservices.

    Of course, organizations have been instrumenting applications for decades. However, the time, effort and cost associated with instrumentation have tended to limit its use to only an organization’s most mission-critical applications. The issue now is that not only do microservices-based applications require instrumentation to manage them but in the age of digital transformation the percentage of applications deemed mission-critical is also steadily rising.

  • How to Achieve AWS Competency Accreditation

    How to Achieve AWS Competency Accreditation

    For businesses in the early stage of their ventures, proving that they have the expertise and technical know-how when it comes to cloud technology can be difficult. An acceleration toward digitization due to COVID-19 and an increasingly crowded cloud market, dominated by the big players, means that simply shouting about your skills in cloud engineering and DevOps isn’t enough to get noticed.

    But what if you can work alongside these giants? Joining forces with expert brands and entering into endorsement partnerships can propel your business forward by supplementing it with seasoned expertise. Accreditation, if you can achieve it, can give you a stamp of approval and reassure prospects that you have the relevant knowledge to support their digital transformation efforts. Collaborating with industry leaders on skills accreditation programs is a great way to demonstrate your capabilities and provides clear goalposts to work toward when it comes to building and learning.

    So, how do businesses achieve this status and what are the long-term benefits of the process?

    Become an AWS Partner

    Achieving accreditation as an AWS DevOps Competency Partner takes a lot of hard work and investment into building the technical skills required to reach such a high standard–logging and evidencing every action your team takes is no mean feat. From beginning to end, the course takes around six months. The process begins with researching and selecting which specific competency your team is interested in achieving. It’s important to understand which competency your business is most suited to, so doing your homework is key. From there, there’s a lot of work to evidence, certificates to achieve and reviews to undergo. Becoming an accredited AWS partner brings a multitude of benefits to your brand, so it is well worth the investment.

    Top Tips for the Accreditation Process:

    Create detailed accounts of your work: To become a certified DevOps partner, businesses need to evidence four case study examples; two public and two private. As such, it can be useful to bring in a tech writer to consolidated your notes and observations throughout the process. We began, for example, with a technical exploration from the team to understand the best case studies to put forward; our work had to be clearly evidenced with strong examples and the documentation to back it up which took a considerable amount of time to pull together. Maintaining clear and detailed accounts of previous work can prevent any delays. This information is firstly analyzed by AWS to check that it met the specific requirements before being passed on to be examined by a team of external auditors, so every detail counts when it comes to showcasing your work.

    Prepare the marketing team: As part of the process, businesses are required to have certain marketing collateral in place across their website to aid with lead generation. For the DevOps competency certification, we needed to evidence three technical blogs–businesses applying for the certification need to ensure that the content best reflects their expertise in the given competency. Once the accreditation is finalized, the partnership should be displayed on the site. Even if a business is tech-agnostic, demonstrating your skills in a particular type of cloud engineering is highly valuable to your brand and AWS is a respected platform to use.

    Advance technical training in the workplace: Having members of the team qualified in cloud engineering is another requirement for accreditation. For DevOps, we needed eight people on the team to have achieved their associate certifications and four to have achieved professional certifications. To fulfill this requirement and ensure we’re on top of our game when it comes to cloud training, we’ve invested in third-party tools, provided access to LinkedIn Learning programs and we give our people additional time off from client-facing work to prepare for their exams. Building and learning in tandem is the fabric of our culture, and a similar approach would benefit any company looking to achieve certification status.

    The Benefits of AWS Accreditation

    Being able to showcase a close association with a major player such as AWS opens up a number of doors for smaller businesses. Operating within this kind of business ecosystem provides the opportunity to demonstrate a business’ DevOps and technical skills to an enormous global audience which can drive new business conversations and drive quality leads. Confirmation that your business is a trusted partner for a major cloud organization will ensure that prospects have confidence in your capabilities and you’re taken seriously as a technical player in the market. Building confidence within your teams and supporting them in their learning is an investment that will pay huge dividends.

    Working alongside AWS as an accredited DevOps partner gives us a springboard to talk about our work and engage with other players in the market. The accreditation is a fantastic talking point and definitely gets you noticed in the cloud community–plus, you will be taken more seriously as a partner.

    Investment in Cloud Tech is Key for the Future

    As businesses everywhere begin to operate in an increasingly digitized environment, technical skills and cloud expertise are a necessary investment for any business. Working toward coveted industry accreditations while prioritizing long-term skills training is imperative. It’s a competitive, buoyant market for cloud engineers and DevOps at the moment; opportunities are at their fingertips and if they aren’t feeling fulfilled by their current work, they’re likely to look elsewhere. Investment in training and nurturing growth in this way breeds employee engagement and loyalty. For a company to thrive technically, it needs to host a wide range of diverse talent and be able to retain it. Learning opportunities should always be the key focus.

    The shortage of this talent means it’s critical to advance the business’s cloud expertise by pursuing recognition from major global players like AWS. Providing advanced training and certification opportunities for your people will ensure long-term talent retention while making the business a leader in cloud engineering. That’s pivotal for long-term success.

  • Popular iOS Apps Request Excessive User Data Permissions

    Popular iOS Apps Request Excessive User Data Permissions

    Most apps require some sort of user data to function properly. Google Maps needs location data to offer routing services. Twitter needs photo library access to upload a photo, and so on. Many users are quick to allow access to personal information without hesitation. However, in recent years, it’s become apparent that many apps are collecting (and leaking) an excessive amount of personal data, resulting in serious privacy issues. This has led Apple to give user privacy a heightened focus in recent iOS updates and marketing campaigns.

    Often, user data is being collected in the background for legitimate use cases, such as tailoring personalized user experiences and refining app performance. But, many apps are also monetizing user data by reselling it to third-party advertising data brokers without explicit user consent. More seriously, recent studies show that commercially available “anonymous” data can be de-anonymized. If location data is exposed, it could put at-risk people in actual danger. These are nuanced privacy violations that U.S. regulators have yet to respond to and address.

    To shed light on the data that apps are collecting, a recent study conducted by Jamf analyzed the iOS permissions requested by nearly 100,000 popular apps on the App Store. The study found the four most-requested mobile app permissions to be photo roll, camera, location data and microphone. The findings also revealed that popular apps are consistently requesting access to data that does not serve the application’s core purpose.

    Users should consciously be aware of the data they allow apps to access. Yet, the onus is also on business leaders and app developers to limit unnecessary data collection and reduce the potential for data overexposure. In the wrong hands, access to device hardware, such as a microphone or camera, could be used to steal sensitive material. And, if leaked, personally identifiable information (PII) exploits could be disastrous to the business.

    Below, I’ll review the key takeaways from the Jamf study and consider if the constant barrage of permissions requests is exacerbating privacy issues during the application development process.

    Four Most-Requested App Permissions

    The Jamf research found the top four types of app permissions were photo library access, camera access, location data and microphone access. In addition, other popular areas included calendar information, contacts and Bluetooth. Less-requested app permissions included voice processing, health data and local network access. The study arranged apps by their App Store categories, such as business, education, entertainment, news, shopping, travel and other areas.

    user data permissions

    1. Photos

    By far, the most requested data access type is photos. At least half of apps across all categories request access to user photo libraries. Naturally, this request is most common among photo and video apps such as YouTube, FaceApp or Splice; 96% of such apps request access to photos. This is followed by 87% of shopping apps (Amazon, Shop, eBay, etc.), and 84% of social networking apps (Facebook, Instagram, Twitter, etc.).

    At issue here is that the level of intended photo library access can be highly variable. For example, granting access to an entire camera roll along with decades of old personal photos just to upload one picture grants a rather invasive privilege. This has led Apple to enhance privacy controls—users can now choose to allow access to select images only or their entire roll.

    With these new constraints in mind, app developers should take steps to respect user privacy. Be aware of potential photo limitations and design apps to only collect necessary photos for the task at hand.

    2. Camera

    The next-most requested permission is for camera access. This is most common among photo and video apps, among which 90% request camera access. This is also common among shopping and social networking apps (83% each) and business apps (75%) like Zoom, Slack or WebEx. Similar to findings about photo library access, enabling camera access is ubiquitous. However, it is also one of the most dangerous permissions to grant indefinitely. If a bad actor obtained account access, this vulnerability could enable them to spy on users.

    Again, developers should consider introducing camera functions only when it’s essential for the task at hand. Obviously, it’s unethical to invoke camera access when users are unaware. Even camera-related bugs can have extreme repercussions. For example, a 2020 lawsuit against Instagram argued the app was spying on users. Due to its threat potential, high-security facilities have disabled camera hardware entirely.

    3. Location

    Location tracking is another permission that can be very useful but is, at times, overprescribed in modern app development. Location data includes cellular, Wi-Fi, GPS and Bluetooth data used to determine a user’s approximate location. The categories that collect location data most often include shopping and food and drink, both at 81%. Social networking and photo and video app categories follow at 72% and 68%, respectively.

    Nowadays, iOS privacy settings offer a check against tracking location data in the background. iOS users can now choose between: ‘Allow While Using App’, ‘Allow Once’ or ‘Don’t Allow’.

    user data

    When an app tracks data in the background, a blue indicator now displays in the status bar to increase user awareness. iOS also reminds users when apps use significant amounts of location data and offers ways to turn location services completely off. Android has followed suit with an ‘Allow only when the app is in use’ function, too.

    user data

    Location tracking feels a bit creepy. In the wrong hands, it could easily be leveraged for nefarious purposes. Out of all the permission-granting options, location data presents much more of a physical safety concern for the end user. From the user’s standpoint, they should only enable access to location tracking while using an app. From a developer’s standpoint, they should be extremely careful when collecting and storing such PII to ensure regulations aren’t broken.

    4. Microphone

    Lastly, access to the user’s microphone is the fourth most commonly requested permission. The survey found 69% of social networking apps, 64% of photo and video apps and 41% of both business and productivity apps (Asana, Google Calendar, TimeTree, etc.) all want to be handed the mic.

    Here, potential privacy concerns are similar to those involving camera access. Bad actors could potentially activate the mic to listen to private conversations, record ambient noise and sell findings to advertising brokers. To increase user awareness, iOS 14 now requires an orange dot to display, indicating when the mic is in use.

    Other User Privacy Concerns

    User behavior tracking and app-to-app information exchange is another ongoing area of privacy concern. Companies often resell such information to data brokers, which is then used to refine highly targeted ad campaigns on third-party sites. This is how your search on Google results in product advertisements popping up in your Instagram feed. Apple is just starting to counter this practice with their App Tracking Transparency feature. In iOS 14.5, app devs must ask whether they can track your activity.

    Recent analysis has confirmed that commercially available consumer data, though labeled as “anonymized,” can successfully be used to piece together an accurate picture of a user by corroborating behavior on other apps. For example, users were able to track and pinpoint behavior that resulted in the outing of a catholic priest on Grindr. Smartphone app data could similarly be used by predators to spy on celebrities or politicians, posing a tangible security threat.

    Another cause for concern is metadata associated with photos. People often enable GPS-embedding into images to help organize their photo memories. If this is inexorably linked to photos, it essentially permits location data sharing to parties with photo library access who might not otherwise have location tracking permissions.

    From Big Data to Big Problem

    Perhaps the most curious finding of this report is that all apps are requesting permissions that seem irrelevant to their core value proposition. For example, why do 87% of shopping apps need access to a user’s entire photo library? Do 46% of food and drink apps really need access to a user’s personal contacts to place a food delivery order? Do navigation apps really need your personal calendar information to calculate a route downtown?

    The answer is not a pretty one. There has been a business imperative, for years, to track and collect large amounts of user data. There is undoubtedly an argument to be made for enhancing the user experience with innovative features and the role of big data in AI. However, this ongoing practice continues to creep into ethical gray areas. The fact is, the more personal data an app collects, the more potential privacy issues and security threat vectors are created in the process.

    Requesting permissions to on-device hardware and data collection is not always necessary. Thus, to stay safe and limit data overexposure, don’t overprescribe data collection. If it’s not fundamental to your app’s core function, don’t collect it, and don’t store it. Think twice before requiring many device permissions, and regularly audit app permissions requests to keep them to a minimum. As iOS and Android introduce new platform guidelines to elevate user privacy, developers should be prepared for users to grant fewer and fewer data collecting permissions. This is their right.

    It would be great if tech companies invested in honest, ethical business models that didn’t rely on harvesting and reselling user data to shady advertisers. And for those that mine user data but say it’s anonymous, I would point to reports that show anonymous data is nothing but pure myth.

  • GitHub Updates CLI to Make Creating Extensions Easier

    GitHub Updates CLI to Make Creating Extensions Easier

    GitHub this week made available an update to its command-line interface (CLI) that enables DevOps teams to add extensions to workflows.

    Billy Griffin, director of engineering for GitHub, said the company’s initial focus was providing DevOps teams with a set of workflows that could be invoked easily via a CLI. Now GitHub is encouraging developers to extend those workflows using version 2.0 of its CLI that hopefully will be shared with the larger community, he added.

    For example, extensions have already been created that order branches by how recently they were created and then display all associated pull requests.

    At the other end of the spectrum, developers are creating simple screensaver extensions for their own amusement.

    The level of interest in extensions varies widely across DevOps teams. Many of them simply want to employ an opinionated workflow that has been created on their behalf. Other DevOps teams want to be able to make modest modifications. Others prefer to customize workflows as much as possible to fit their specific purposes. Version 2.0 of the CLI provided by GitHub enables each DevOps team to decide how much to modify their workflows. However, as a DevOps team gains more experience, increasingly they tend to want to customize workflows.

    The number of workflows being created around the GitHub repository continues to increase steadily as more organizations embrace best GitOps practices. GitHub is the most widely employed repository for managing software artifacts, and the level of sophistication of workflows built using either scripts or GitHub actions is increasing steadily. Much of that effort is focused on streamlining processes that otherwise would get in the way of enabling developers to spend more time writing code.

    Of course, the pressure on developers to write more code faster has never been greater. As organizations embrace digital business transformation, they are discovering how dependent they are on software to create customer experiences that drive revenue. The challenge comes at a time when many developers are working from home to help combat the spread of the COVID-19 pandemic and many existing workflows need to be re-engineered. At the same time, development teams are becoming more distributed as organizations become more comfortable with hiring developers anywhere in the world.

    It’s not clear to what degree the changing application development landscape might drive organizations to re-evaluate what platforms they are employing to drive DevOps processes. Many on-premises development platforms have been replaced by cloud-based alternatives in the past year. However, because necessity is the mother of invention, the workflows relied on prior to the pandemic are not only now forever changed, but they will also likely be altered again as development teams work more intermittently in-office and from home once the pandemic subsides.

    Regardless of how those workflows evolve, the single-valued DevOps attribute is going to be flexibility. The challenge now is determining which platform does the most to enable that flexibility at a time when uncertainty continues to prevail.

  • How to Optimize Data in Software Development

    How to Optimize Data in Software Development

    Data can drive significant business value for every company. Globally, we are collecting more of it than ever before, and it keeps growing—from 45 zettabytes in 2019 to a projected 175 zettabytes by 2025, according to IDC. However, companies are struggling to monetize all the personal, behavioral, engagement and transactional data from customers and operations and turn it into actionable intelligence to drive their digital strategies. Leveraging insights from your data is critical for success and the development of new digital solutions to better serve customers, grow sales, improve operations and more.

    Data helps organizations develop the right software for the right customer at the right time. Data-driven organizations are 23 times more likely to acquire and retain customers than their peers, and are growing at an average of more than 30% annually, according to Forrester.

    Organizations with a deep and dedicated focus on data and analytics tend to follow three common paths to successfully drive their software development initiatives.

    Discovery Matters

    It is nearly impossible to draw value, understanding, and insights from the massive amount of data businesses collect without a proper discovery system in place. Having a comprehensive process of collecting data from various databases and silos and consolidating it into a single source that can be easily and instantly evaluated is critical for any software development project.

    During client engagements, data scientists perform deep-dive research into clients’ data pools and workflows to support client roadmaps. We recently partnered with a global e-commerce company to create a recommendation system for their customers. The discovery process allowed us to verify the feasibility of recommended products using their existing data before moving ahead with the project. Using machine learning, the team was able to clean and analyze information from multiple angles. With that knowledge and confidence, the rest of the development project proceeded quickly knowing the data was in place and the project was viable.

    Align KPIs

    Software development metrics help organizations and their partners track and measure how an application is performing and how effective the development team is in its work. IT organizations rely on a range of KPIs to fully understand software engineers’ progress, as well as gauge software quality including performance, engagement and user satisfaction. While each engagement is different and requires a different set of KPIs, ensuring that the organization and development team are on the same page is crucial.

    During the e-commerce project, success was measured through conversion and user retention rates. Other KPIs that are regularly used include developer productivity and performance metrics like cycle time and team velocity, and software developer metrics like response time, usability and UX data, among others.

    Deploy Agile

    By using agile methodologies at all stages of development, developers are able to focus on business results, not just architecture and new technologies. A similar agile approach can also be applied to data management. When it comes to data science, it’s all about extracting useful information from raw, structured and unstructured data and implementing machine learning models to analyze vast amounts of information. This process requires more creativity and is a key driver for understanding potential risks and failures over the course of any given project.

    With agile, data models and analyses are broken down into manageable bite-sized chunks that can be built and tested quickly—the same way software is developed. If the analytics do not yield the expected results, data scientists see the failures immediately and can correct their course. They could ask the team to analyze different data sets, adjust the models, tweak algorithms or make an educated decision about the project’s viability.

    A multinational credit company took this approach to the next level when it used agile to develop a new, big data hybrid cloud platform. After anonymizing, aggregating and storing information in a data lake, the team quickly realized the database it was planning to use was limited to a certain number of partitions and entities. By running agile sprints and developing and testing the minimum viable product (MVP) continuously, the team was able to seamlessly switch to a new database that had more scale and functionality.

    The value of data is only going to increase with time. Data-driven organizations embrace the use of data and analytics to gain unique business insights to support their software development projects and overall business. By focusing on the data in each and every development project, companies have a tremendous opportunity to gain a competitive advantage and grow their businesses.

  • F5 Networks Planning Open Source Projects Beyond NGINX

    F5 Networks Planning Open Source Projects Beyond NGINX

    F5 Networks today revealed plans to launch multiple projects in the months ahead that will extend its commitment to open source beyond the NGINX proxy software the company acquired in 2019.

    The announcement was made during an online NGINX Sprint event; two of the projects are extensions of NGINX that will address networking requirements between microservices-based applications in addition to the management of fleets of NGINX instances. The third project is a platform-agnostic open source developer tool for building modern applications that does not necessarily require NGINX proxy software.

    At the same time, F5 Networks also unveiled an open source NGINX Modern Apps Reference Architecture that gives IT teams access to a complete, fully operational microservices-based application that can be deployed in minutes on a Kubernetes cluster. Based on a modular approach made up of open source components that come pre-wired and pre-integrated, F5 Networks is committing to extending this framework in collaboration with multiple third-party vendors and organizations.

    F5

    Rob Whiteley, general manager for the NGINX product group at F5 Networks, said the company is also committing to modernizing its NGINX proxy software to leapfrog rival open source Envoy proxy software being advanced under the auspices of the Cloud Native Computing Foundation (CNCF). NGINX is still more widely employed than Envoy largely because it is lighter-weight and easier to deploy, but Whiteley conceded that Envoy has more advanced capabilities.

    Envoy, of course, is at the core of the Istio service mesh. F5 Networks supports both Istio as well as a service mesh it has developed on top of NGINX. Depending on the number of application programming interfaces (APIs) that an organization needs to support, an IT team might make use of proxy software, ingress controller or an API gateway for a service mesh to manage them.

    Finally, F5 Networks said it will participate in the Kubernetes ingress project and that it is joining the gateway API community as its implements its own NGINX-based gateway controller to ensure its proxy software and Kubernetes remain tightly aligned in the future.

    In general, Whiteley said F5 Networks also is making a commitment to be clearer about where the line between the open source and commercial editions of its offerings is drawn. As a rule, the open source editions are designed for developers and small teams while the commercial version is designed to scale within enterprise IT environments. The overall goal is to promote innovation without enabling cloud service providers to reap all the revenue benefits of F5’s research and development by creating a service based on that open source software, said Whiteley.

    As part of that effort, F5 Networks is expanding the number of open source projects it supports to make it easier for developers to contribute code beyond the core NGNIX proxy software, said Whiteley.

    It’s not clear to what degree F5 Networks will be able to rally the open source community to advance additional projects beyond NGINX. The company is promising to provide additional details at an unspecified future date. However, Whiteley said there is still plenty of room for innovations not only in emerging technologies such as service meshes but also proxy software that is already widely employed within many enterprise IT organizations. Especially since most of them are embracing microservices-based applications that will ultimately change every aspect of IT.

  • Why You Should Use GitOps to Experiment With AI

    Why You Should Use GitOps to Experiment With AI

    As the pace at which artificial intelligence (AI) models are being constructed and inevitably updated starts to increase, it’s becoming more apparent that the pace at which data science teams are currently experimenting also needs to dramatically quicken.

    Many data science teams today are fortunate if they manage to successfully deploy two AI models in a production environment over the course of 12 months. It’s already apparent, however, thanks in part to the rise of digital business transformation, that there are potentially hundreds of use cases for AI models within each enterprise IT environment. Truth be told, it’s hard to envision an application being developed today that would not incorporate one or more AI models. The challenge is, the demand for AI capabilities is now far outpacing the ability of data science teams to deliver.

    The best way to solve this issue is to recognize that AI models and the components employed to construct them are, in reality, just another kind of software artifact. In fact, the need to accelerate the development of applications using artifacts is largely a problem already solved. Rather than reinventing the wheel, the time has come to apply what we already know to the development of AI models.

    The Rise of GitOps-Based Processes

    Modern software development teams today routinely make use of Git-based repositories to share code and collaborate. These repositories are jam-packed with vetted software artifacts that development teams continuously reuse via an opinionated instance of a DevOps workflow based on a set of GitOps best practices.

    As a subset of DevOps, a GitOps workflow enables data science teams to employ a Git repository that already exists within their software development environment to manage artifacts. Git enables versions of files to be created using what is known as a Git branch. They also employ concepts known as tags (Git Tag) and remotes (where the server is located). Those three different concepts, or references, exist under the hood in Git. In fact, the entire flow is based on those concepts. When a new feature is implemented, a new branch is created and then merged into the production branch with a tag that says something like “This is a new version that needs to be deployed.”

    An AI model, like any other software artifact, needs to be updated. As new data sources become available, an AI model is likely to drift beyond the parameters originally intended. A rapid change in business conditions may also require changes to an AI model. The same processes that DevOps teams apply to update any software artifact can also be applied to rapidly update an AI model. Employing a Git repository to also manage AI artifacts extends the benefits that software development teams enjoy to data science teams.

    Often, organizations will have an MLOps solution to streamline AI model development that is completely separate from their DevOps tools. These solutions will have dedicated features like version tracking for data and experiments specifically for AI models. But many MLOps solutions exist in a closed ecosystem, meaning they don’t work off of existing tools like GitHub used on the DevOps side. 

    Also, data science teams have to separately buy, deploy, and manage these closed MLOps solutions. Going with a GitOps-oriented solution streamlines management of added MLOps tools and makes it easier for both application developers and data science teams to gain visibility into each other’s respective efforts. The end result is not just faster AI experimentation at lower cost; the likelihood that more AI models will successfully be deployed in a production environment increases dramatically. 

    Software and AI Teams Working Together

    The convergence of DevOps and MLOps is already inevitable. The longer organizations continue to employ isolated MLOps platforms to build and deploy AI models, the more expensive it will become to meld MLOps and DevOps processes. 

    Data science teams are conservative by nature. The difference between success and failure often comes down to how thoroughly an AI model is validated. However, time to market doesn’t have to be sacrificed to ensure an AI model works as promised. There is no such thing as a great AI model that arrives late when rivals are racing to develop similar AI capabilities—there are only missed opportunities. Speed enabled by the reusability of artifacts that drives faster experimentation using GitOps workflows is of the essence now more than ever.

  • Low-Code is Table Stakes for Enterprises

    Low-Code is Table Stakes for Enterprises

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

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

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

    Speed is Table Stakes, But So is Low-Code

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

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

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

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

    What Does Low-Code Mean?

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

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

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

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

    Generating ROI From a Low-Code Platform

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

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

    Low Code is Here to Stay

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

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