devopsy.kinsta.cloud

Category: Features

  • Cycloid Tool Can Reverse Engineer Provisioned IaC

    Cycloid Tool Can Reverse Engineer Provisioned IaC

    Cycloid this week unveiled a tool that makes it possible to reverse engineer code used to manually provision cloud infrastructure. The Infra Import tool is part of an effort to create a more consistent and reliable version of that code using open source Terraform software.

    Benjamin Brial, Cycloid CEO, said Infra Import is based on Cycloid’s open source TerraCognita software, which enables IT teams to reverse engineer infrastructure-as-code (IaC) created using open source Terraform tools.

    Infra Import extends that capability to cloud platforms such as Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform or an IT environment employing the open source OpenStack cloud platform that may have been manually provisioned. IT teams can then create a configuration based on that Terraform code that could be employed across multiple clouds.

    Infra Import is designed to connect to a cloud provider and then automatically reverse engineer Terraform files and IaC stacks based on the existing deployment. It also ensures that the latest edition of Terraform is being used to create that configuration code, noted Brial. That capability eliminates the need for DevOps teams to keep track of what version of Terraform might need to be updated as new versions of the IaC tool become available.

    Just as significantly, Infra Import also makes it a lot easier to onboard new members to a DevOps teams because the tools uses valid secure configurations they know can be relied on. Misconfiguration of cloud services is one of the biggest security issues that IT teams today are wrestling with, simply because most developers lack the security expertise required to configure cloud services properly.

    Cycloid is in the process of rolling out a comprehensive suite of management tools that complement a lightweight framework it created to make DevOps best practices more accessible. The challenge is many IT organizations have already manually provisioned cloud infrastructure in a way that is, at the very least, often suboptimal if not downright insecure.

    Misconfigurations are rife across cloud computing environments, but most organizations are not prepared to manually address the issue. Automating the reverse engineering of those configurations is the first step toward enabling IT teams to address the problem at scale.

    It’s not clear to what degree configuration concerns have impacted the number of applications that would otherwise have been deployed in the cloud. Security is always listed as the top concern IT leaders have when employing cloud platforms. The issue, however, is not the security of the platforms themselves but rather the processes employed to deploy applications on the platforms. Cloud service providers have promoted a shared responsibility model for security under which developers are accountable for both securely configuring services and ensuring the overall security of the software environment. The trouble is, not every developer understands the implications of that shared responsibility model much less how to actually secure an application workload.

    It’s not likely security concerns will slow down the rate at which applications are deployed in the cloud. However, as more cloud security issues are encountered, more scrutiny will be applied.

  • Logz.io Allies with Microsoft on Open Source Observability

    Logz.io Allies with Microsoft on Open Source Observability

    Logz.io this week announced an alliance with Microsoft that enables DevOps teams to deploy its observability platform—based on open source platforms such as ElasticSearch, Logstash, Kibana (ELK), Prometheus and Jaeger—on the Azure public cloud.

    Jonah Kowall, Logz.io’s CTO, said the multi-year effort enables those teams to deploy the Logz.io platform via the Azure Console with the click of a button. The Azure platform has a data collection capability that aggregates operating system events in a way that makes it simpler for the Prometheus monitoring solution to consume, he added.

    DevOps teams, however, will still have to collect data from the applications they instrument on the Azure platform, he added.

    Logz.io integrates multiple open source monitoring tools based on metrics, logs and traces within a single observability platform that otherwise would require considerable time and effort from internal IT teams on their own.

    Interest in observability is rising as organizations attempt to provide internal IT teams with more context when troubleshooting issues. Whenever there is an IT issue, most teams convene a “war room” where they attempt to discover the root cause of an issue by comparing analytics generated by a wide range of monitoring tools. Observability platforms promise to enable a DevOps team to replace many of those tools in a way that provides more context by integrating log data, metrics and distributed traces within a single platform.

    In many instances, existing application performance management (APM) platforms are being transformed into observability platforms by adding tools to monitor IT infrastructure. Conversely, platforms for managing IT infrastructure are adding support for tools to monitor applications. Elsewhere, a range of startups have emerged to offer observability platforms they have developed from the ground up.

    Regardless of the platform employed, the rise of microservices-based applications within many organizations is forcing the observability issue. The dependencies that exist within microservices-based applications are too complex to manage without a platform that provides some level of increased observability. Of course, most existing monolithic applications are not being retired any time soon, so the need for an observability framework for both legacy and modern cloud-native applications has only become more pressing.

    The Logz.io platform can, of course, be deployed on other cloud platforms as well as within on-premises IT environments. As hybrid cloud computing continues to evolve, it is apparent that observability platforms will need to extend their reach from the cloud to the network edge. Over time, artificial intelligence (AI) capabilities will be added to make it easier to, for example, streamline the number of alerts that are generated across complex IT environments.

    In the meantime, the most important thing with regard to observability may be simply getting started. Most IT teams start to analyze logs before moving on to metrics and then traces using the open source Jaeger agent software. After all, the only thing more difficult to instrument than an application before it is deployed is, arguably, one that is already running in a production environment.

  • Learning from Loris Degioanni: Cloud-Native Days with Kubernetes Virtual Summit

    Learning from Loris Degioanni: Cloud-Native Days with Kubernetes Virtual Summit

    Keeping up with information can be challenging. With all these changes, you’re probably left wondering, “who can guide me through all this information?” Fortunately, Cloud-Native Days with Kubernetes is focused on giving attendees the tools they need to become proficient in cloud-native technologies. At the virtual summit, attendees can tune into our expert-led featured sessions and learn how to leverage cloud native technologies to move faster and more securely.

    Cloud-native technologies are quickly becoming an integral part of IT environments as organizations continuously accelerate their development efforts to meet business demands. Because of this, it’s incredibly valuable to learn from industry specialists changing the IT world as we know it. And who better to learn from than the industry thought leaders and doers in the cloud-native space? Through sessions touching on topics like security and observability, our featured tech titans will give you a better understanding of cloud native and its impact on the IT landscape.

    Today, the CI/CD pipeline is mainly built on open source tools – Kubernetes, Jenkins, GitLab, etc. Security has traditionally been closed, but it’s now clear the pace of innovation cannot be constrained by proprietary development models. Keynote speaker Loris Degioanni, CTO and founder of Sysdig, will discuss key practices needed for a secure cloud and container environment, including: what is required to increase security, visibility and simplicity in the cloud, lessons learned from major attacks like Kaseya and SolarWinds, ways to leverage Secure DevOps to not only ‘shift left,’ but also ‘roll right’ for detection and response, and how open source is the key ingredient to see all your signals in a constantly changing landscape.

    In his article, “Open Source is Taking Over Security,” published last year on The New Stack, Loris Degioanni elaborates on this idea that open source is essential to maintaining high security, stating, “I argue that, despite having lower penetration of open source, security is the industry that benefits the most from an open source approach. I also argue that open source will gradually take over and become the standard way to do security.” To understand this further, Loris breaks it up into a few key questions: Why is open source the best way to do security? and, Will open source become the standard way to do security?

    Let’s start with the most important question: Why is open source the best way to do security? Loris is adamant that open source is the key ingredient to security because of one thing – speed of innovation. Loris points out that the rise of widely adopted and open computing platforms like Kubernetes have had a big impact on how distributed, coordinated ecosystems can beat out a ‘behind closed doors’ single vendor 100% of the time. Loris writes, “On one hand, Kubernetes and cloud native have such a fast innovation pace that it’s hard for a vendor to keep up by itself. On the other hand, thanks to Kubernetes, for the first time we have a completely open platform to run our applications, where security can be natively integrated rather than being bolted on top.” 

    Open source also increases the speed of innovation because it empowers end users to work with vendors. Any user, regardless of size and level of sophistication, Loris says, can provide feedback in a tight loop and they can also contribute. So why is this relevant to security? As Loris explains, “The intrinsically fragmented nature of vulnerabilities and threats makes this bazaar-oriented approach to contributing very effective.”

    This brings us to Loris’s second question: will open source become the standard way to do security? Not only does Loris say yes, open source will become the standard way to do security, but in fact there is no escaping this. Using a metaphor of bad guys vs. good guys to describe cybersecurity battles, Loris says, “the army of the bad guys is big, smart, and aggressive. And the deck is stacked in their favor.” 

    So how do the good guys win in this scenario? Loris says the best chance at this is, “working together, as a team, leveraging each other’s strength, making sure that no energy is wasted.” Rather than having competing standards upheld by a variety of vendors, Loris is adamant that “a much better approach consists of leveraging a common set of standards that are deeply integrated in the platform, owned by the community, driven by consensus, on top of which all of the players can confidently innovate.”

    Much like Loris’s approach to open source, innovation and security are also valuable key practices at Cloud-Native Days with Kubernetes. Life moves fast. Innovation cannot afford to be slowed down, especially now. So begin your cloud-native information journey by tuning into our expert-led sessions, gathering your questions and learning from our talented speakers August 4 and 5 at 9 a.m. ET.

  • 12 Ways to Bake Security Into a DevOps Transformation

    12 Ways to Bake Security Into a DevOps Transformation

    Security has become an integral part of any DevOps transformation. According to the Upskilling 2021: Enterprise DevOps Skills Report, DevSecOps achieved a must-have percentage vote of 56% in the automation tool category. Security not only protects the business and its customers, but it enables companies to enforce internal and external policies. 

    While considering how to bake security practices into a DevOps transformation, I asked several speakers and sponsors for the upcoming SKILup Day as well as several DevOps Institute Ambassadors to weigh in with their thoughts. Here’s what they shared: 

    Sponsor, Kendall Miller, president, Fairwinds

    “A DevOps transformation is about building great tooling so that developers can own their services all the way into production. The addition of security is the same thing; it’s building great tooling so that developers can also own the security posture of their services all the way through to production. This transformation is about enabling developers to understand security concerns at the application level. Service ownership is still service ownership—ownership of the operational and security pieces.”

    Sponsor, Guy Eisenkot, VP of product, Bridgecrew by Prisma Cloud

    “The key to a strong DevOps transformation that keeps security at the forefront is selecting and leveraging tools and processes that lend themselves to automation for your specific stack. For AppSec and cloud security alike, automation is the name of the game. But automation is only as strong as the processes it can fit into and the feedback it provides. 

    Security feedback will be futile if it’s not actionable and not given at the right time or in the right place. When undergoing a DevOps transformation, it’s important to keep that in mind when implementing tools and processes. It’s also important that the feedback surfaced is actionable and useful so that engineers can actually learn from and implement secure coding practices.”

    Sponsor, Rob Cuddy, global application security evangelist, HCL Software DevOps

    “The best place to start is with design and make sure that your epics, stories, hill statements and use cases all have security elements as part of them.  A great idea here is making ‘misuse cases’ or adversarial use cases and then testing against them.  For example–a misuse case might read, ‘As a bad actor, I can use a malformed URL to gain unauthorized access to a web server,’ or ‘As a bad actor, I can impersonate an endpoint in a transaction and both send and receive data while impersonating without the other parties’ knowledge.’

    It is also vital to have great SCA–software composition analysis. You cannot secure what you don’t know you have, and this includes open source and third-party tools. In a lot of cases, simple code sharing can inadvertently cause dozens of new dependencies to be added in, and those dependencies can add new vulnerabilities.

    It is important to have security aspects tested and validated throughout a pipeline, but particularly at any points in the pipeline where other checks are also being made. A great place to combine this is in QA and wherever functional testing is being done.  Leveraging interactive security testing (IAST) in an environment like this allows for monitoring to occur and for vulnerabilities to be found while application capabilities are being tested.  This greatly reduces the appearance of false positives and provides real-time information about the security posture of applications.”

    Sponsor, Yasser Fuentes, cloud workload security technical product manager, Bitdefender

    “In short, security should not just be considered at the CI, dev and test phases or limited to vulnerability assessments, since most of the vulnerability scanners and assessment tools DevOps teams use today to go over their CI/CD pipelines rely on either known vulnerabilities, signatures and known attack techniques. As a recommendation, we should emphasize the importance of incorporating tools or solutions which allow developers to identify potential threats and security flaws at the runtime level and which provide visibility beyond the typical anti-malware alerts to suspicious and potentially anomalous process-related behavior.” 

    Sponsor, Joni Klippert, co-founder and CEO, StackHawk 

    “To bake security practices into a DevOps transformation, teams need to reimagine how security plays in the software development life cycle. For many organizations today, security testing blocks applications from being shipped into production or tries to play catch-up once software is released. But it doesn’t have to be that way. 

    Security can (and should) live throughout the pre-production phases of software development. Modern security tools automate security testing in the IDE or CI/CD pipeline, alerting engineers if they have introduced a vulnerability or a vulnerable dependency.

    Making security just another type of test that is run in pre-production means teams can find vulnerabilities faster, remediate on the fly and, most importantly, get back to feature development. Baking security into the DevOps pipeline is what all teams should aim for!”

    Stephen Walters, sales engineer, Everbridge

    “The exact same way that any other practice has become baked in as part of DevOps—by following the CALMS principles. Implementing a culture of inclusion and acceptance; integrating automation into security testing, monitoring, builds and repository management; ensuring the flow and feedback of security into delivery and support is performed in a lean way, adding value and not waste; measuring security as a business value through the use of scorecards and as a success criterion for the business; sharing concerns, lessons learned, new practices and techniques.”

    Dheeraj Nayal, global community ambassador & region head – Asia Pacific, Middle East and Africa region, DevOps Institute

    “A proactive approach is the best method for building in the essentials of DevSecOps. This can be achieved by following some best practices.

    1. Teams should be aligned and in-sync
      The first and foremost step in implementing a DevSecOps culture is to train your teams that security is a shared duty of teams from all three systems. Once development and operations units take on the distributed responsibility of guarding code and infrastructure, DevSecOps becomes a routine part of the development cycle.  
    2. Keep the code simple
      Complicated code can carry more security vulnerabilities. And simple code is more comfortable to collaborate on. All your developers should be capable of looking at each other’s code and know what is happening.
    3. Testing
       SAST (static application security testing) is a key security tool that checks security issues regularly and earlier in the development process which enables it to address the issues more efficiently.
    4. Deployment
      To expedite product delivery and add flexibility to the development process, automated deployments are great. One can review properties across the IT infrastructure and implement secure configurations in a system employing an infrastructure-as-code tool.   
    5. Operations
      Operations teams must collude with security practitioners. They are accountable for controlling infrastructure and network arrangements. Operations and security teams unite to set up manual and automated security tests to warrant compliance with network configurations.”

    Peter Maddison, founder, Xodiac Inc.

    “Two main places: within platform engineering to enable the collection of the data you will need for creating visibility, feedback and learning. Next, it is important to engage the security and compliance teams to determine where you can integrate into existing standards or where modifications might be required.”

    Mark Peters, technical lead, Novetta

    “Security practices can be baked in through the standard DevOps approach, through people, processes or technology. Baking in practices with people means getting folks on the ground with your team who can advocate for security. This can happen through having your security experts spend time with the teams, assigning security to be responsible for teams, or even by selecting champions within those teams who regularly interact with security. The first agile principle, after all, is ‘people over process.’

    That component does not allow one to ignore the process.  Building the correct process implies using test-driven development at the start. Every delivery should be tested and those tests should include security testing. Some common security testing, such as code quality, now occurs so frequently many no longer consider it a separate security practice; merely a routine part of development.

    Finally, one can bake processes in through technology. Many security tools allow shortcutting through metrics, logs and traces relayed on the dashboard. These tools evaluate and highlight where security challenges occur. Tools allow integration through infrastructure and maintaining awareness of what functions occur and when. One of the old military strategies uses the OODA loop by John Boyd: observe, orient, decide and act. Just as with intelligence systems in the military, better awareness of your system through dashboards allows one to observe functions within the network, orient against possible problems, decide on a solution and act before those problems ever reach critical mass.”

    Supratip Banerjee, solutions architect, Principal Global Services

    “There are a few ways we can bake security into DevOps:

    1. Security as a mindset: There is a thought process that security in the development process might slow it down. But we must educate teams that the time and effort it takes to fix a security flaw early in the process is lower than doing it later.
    2. Platforms/environment: Proper configuration/sanitation of deployment platforms/environments is extremely important. Infrastructure-as-code (IaC), configuration-as-code, compliance/policy-as-code, secrets management, etc. can help with the process. Increased use of containers and cloud platforms can keep it clean as underlying infrastructures are managed by the provider.
    3. Automation: Include a lot of automation testing in the CI/CD pipeline. Also add static code analysis, third-party testing, AVA testing, code vulnerability checking, container security, intrusion detection and prevention, APM, etc. as automated processes. Make change management, auditing, etc. regular and as self-operating as possible.
    4. Secure architecture: Make sure security is enabled at the time of the software architecture/design phase. An architecture risk assessment must be a mandatory process to catch any design vulnerabilities before development starts.
    5. Culture of curiosity: Create a culture that emphasizes the importance of security, so everyone is interested and ready to discover if anything goes wrong with security in their system.”

    Amiran Alavidze, director of security and risk management, Tasktop

    “DevSecOps is about culture and enablement and making software delivery teams autonomous and efficient. Training and awareness is a core component of that enablement. This also includes focusing on tools that are developer-friendly and automated so that critical security controls are an inseparable part of how things are done, and allows development teams to take on all the responsibility, without a cognitive overhead of expert-level understanding of the security domain.”

    Sharath Dodda, IT development manager, TD

    “By engaging security early in DevOps with as much automation as possible. All the scans that are possible and relevant should be done well in advance in the pipeline, so that the artifact is cleared of all the findings.”

    Learn more about DevSecOps and similar topics, by registering for an upcoming SKILup Day. Or, start your upskilling journey by learning more about the benefits of DevOps Institute membership. 

  • WhiteSource Tool Automatically Fixes Code Vulnerabilities

    WhiteSource Tool Automatically Fixes Code Vulnerabilities

    WhiteSource today announced that it has developed the first-ever tool that automatically remediates vulnerabilities discovered in custom code.

    Rami Sass, WhiteSource CEO, said WhiteSource Cure surfaces recommendations for fixing security vulnerabilities in code that developers can then apply with a click of a button. WhiteSource has a long history of providing tools that discover vulnerabilities in open source software that it tracks via a database it manages, but Sass said customers are making it clear they need a way to automatically remediate those issues in a way that doesn’t adversely impact developer productivity.

    The average developer spends, on average, half a day fixing a single vulnerability, so the impact security issues are having on the rate applications are being developed is significant, added Sass. WhiteSource Cure gives each developer the equivalent of their own personal security expert, noted Sass.

    Developers can either apply the remediation suggested by WhiteSource Cure—that manifests itself as a pull request in a DevOps pipeline—or they can fine-tune it as they see fit, said Sass.

    WhiteSource

    WhiteSource Cure arrived as friction and tensions between developers and cybersecurity teams rise in the wake of a series of high-profile attacks against software supply chains. As a result, organizations are instituting more thorough security reviews of application development projects. The concern is those reviews will dramatically reduce the rate at which applications are being delivered.

    Of course, many organizations are looking to shift responsibility for application security further left toward developers to minimize the number of vulnerabilities that might need to be remediated either just before an application is deployed in an on-premises IT environment or, worse yet, after it is deployed. Trying to achieve that goal within the context of DevSecOps best practices, however, is challenging. Organizations first have to acquire vulnerability scanning tools that developers will actually use, and then provide developers with the training required to identify various classes of vulnerabilities.

    The other big challenge is the time it takes to train developers to recognize vulnerabilities. WhiteSource Cure eliminates the need for developers to become security experts, said Sass. In addition to a commercial offering, WhiteSource is also making available a Community Edition of WhiteSource Cure for open source projects that will forever be available for free to developers working on those projects.

    Sass said that rather than relying on machine learning algorithms and other forms of artificial intelligence (AI) to build WhiteSource Cure, the team that developed the tool found that more traditional approaches to software composition analysis (SCA) provided more reliable results.

    It’s unclear whether the ability to automatically remediate known vulnerabilities in code will render much of the DevSecOps debate moot. However, it’s clear that the simplest path forward toward achieving DevSecOps is, as always, to automate as much of the remediation process as possible. The challenge will be waiting to see how much confidence developers and cybersecurity teams will have in the recommendations generated.

  • CircleCI Survey Shows the Need to Prioritize DevOps

    CircleCI Survey Shows the Need to Prioritize DevOps

    A CircleCI survey of 2,013 business leaders in the U.S. and UK published today finds nearly all respondents (97%) recognize that the success of their business within the next year depends on their software development teams. Despite those findings, well over one-third of respondents (39%) admit their organization is challenged when it comes to innovation and acquiring and maintaining developer skills.

    A full 89% of respondents said they also have a good understanding of how to measure the performance of their engineering teams. However, 40% of companies are still using antiquated metrics such as the number of lines of code written, while another 37% measure story points.

    More troubling still, less than one-third of respondents (30%) said they plan to make adoption of DevOps best practices a priority. On the plus side, only 15% of respondents said they are implementing a continuous integration/continuous delivery (CI/CD) platform for the first time.

    The CircleCI survey suggests that improvements in how software is delivered could be worth, on average, up to $126 million per year. Nearly two-thirds of respondents (65%) said their business is involved in digital business transformation initiatives of one kind or another. Another 20% said they have completed one.

    Jim Rose, CircleCI CEO, said it appears that while more organizations now realize how dependent they are on software, many of them have yet to address issues that fundamentally impact developer productivity. For example, more than half (52%) of respondents don’t allow their software developers to choose their own tools, noted Rose. While there is a clear need for a consistent approach to building and deploying applications, Rose noted that DevOps best practices should not require developers to employ a specific set of tools. Developers are only able to truly innovate when they are able to experiment with different tools, said Rose.

    In general, Rose said DevOps adoption tends to go through various cycles. Many organizations today are looking to reduce the number of tools that make up a toolchain. However, those efforts shouldn’t curtail the ability of developers to innovate. A CI/CD platform that provides the foundation for DevOps workflows needs to be easily extensible, noted Rose.

    It’s not clear to what degree adoption of DevOps best practices have stagnated, but the number of organizations that have implemented DevOps across their entire enterprise remains limited. Most organizations have individual teams that might have adopted DevOps to one degree or another. In many cases, those teams are using disparate tools and platforms.

    Most organizations clearly want to be able to build and deploy applications faster. The challenge isn’t so much mastering DevOps platforms as overcoming many of the cultural issues that conspire to limit DevOps adoption. In time, however, the need to rely more on digital processes will force the DevOps issue. As one organization makes advances—thanks in part to their ability to effectively employ DevOps processes—the more keen rival organizations will be to make sure they don’t lose ground. It may be a while before business executives connect the dots between their ability to compete and the degree to which organizations have mastered DevOps, but it’s increasingly apparent that day is not too far off.

  • Shoreline Platform Automates Repetitive IT Tasks

    Shoreline Platform Automates Repetitive IT Tasks

    Shoreline emerged from stealth today to make available a namesake incident automation platform that eliminates the need to manually perform the same repetitive tasks.

    Anurag Gupta, Shoreline CEO, said the platform is based on domain-specific language, dubbed Op, that provides a simple pipe delimited syntax to integrate real-time resources and metrics in a way that allows DevOps teams to invoke an orchestration engine to automate the execution of a task from the Linux command prompt. Op employs a syntax that is familiar to any IT professionals that currently use shell commands and scripting tools to resolve IT issues, said Gupta.

    That same Shoreline tool, however, can also be employed to create remediation loops that check for issues, collect diagnostics and apply repairs automatically in the background, he added.

    Shoreline

    Shoreline achieves that goal by first collecting metrics on a per-second basis via data collected from open source Prometheus monitoring software. Armed with that data, it then becomes possible to distribute queries to both collect data in real-time and run local loops in parallel to automate repairs, Gupta said.

    The platform employs the JAX and XLA frameworks for machine learning algorithms to reduce the amount of CPU resources required to compute metrics and create alarms. Wavelets are also employed to compress the input metric stream. Finally, queries are portioned across historical data stored in the S3 cloud storage service from Amazon Web Services (AWS) and real-time data collected from each node.

    All Shoreline components are designed to be fault-tolerant, added Gupta. Automation can still run locally to Shoreline backends, even when connectivity is lost. All processes have supervisors to restart when failing and reestablish connectivity.

    Finally, Shoreline provides controls to limit the scope of a manual operator action and automate executions in a given time period to help prevent any errors from cascading through an entire IT environment. That approach makes it possible to safely automate tasks in a way that makes it less likely outages will occur because, for example, a misconfiguration winds up being propagated across every system, noted Gupta.

    While IT environments are arguably more complex than ever, Gupta said it’s the repetitive tasks that take up so much of developers’ time. In the absence of any way to automate those tasks, an IT team will, over time, become increasingly burned out, which Gupta noted inevitably leads to mistakes being made.

    At the same time, Gupta noted the Shoreline platform makes it simpler to onboard new members of an IT team because much of the tribal knowledge that once had to be learned on the job has been captured within an automation platform.

    The arguments for automating IT have, of course, been growing louder and more frequent for nearly two decades. Most platforms that promise to automate IT have required a fair amount of expertise to implement and maintain. The Shoreline approach, in contrast, starts with a Linux prompt that many IT teams already routinely use to execute a range of tasks. The difference now is simply the level of scale at which those tasks can be performed with a minimum of programming skills.

  • DevOps Database Platforms Slash DX Bottlenecks

    DevOps Database Platforms Slash DX Bottlenecks

    An enterprise with many databases and various data requirements for DevOps continuous delivery presents a problem. For example, test data provisioning is a challenge today, particularly in pre-release testing of database updates. Standard practices involve shared database environments that need to be maintained from one test to the next, slowing test cycles and generally not fitting into an automated CI pipeline. As I explained in A New DevOps Database Platform is Needed, at best, it makes things chaotic; at worst, problems with database integrations with DevOps is a gross impediment to overall organization agility—which undermines the very purpose that DevOps is meant to serve.

    A recent whitepaper, A New Kind of DevOps Database Platform, indicates that there are multiple reasons why a new kind of DevOps database platform is needed, which are:

    • Compatibility requirements
    • Integration with current CI/CD pipelines
    • Integration with portfolios of value stream management
    • Infrastructure cost efficiency
    • Productivity for developers, testers and operations
    • Security and governance
    • DevOps performance

    The paper explained that a DevOps database platform requires the following capabilities to satisfy these requirements.

    • Automated database provisioning: the ability to deploy a database using automated procedures.
    • Database cloning: writable database environments are delivered on demand, based on a built versioned image.
    • Distributed repository: database images can reside on Linux and Windows servers, as well as storage systems.
    • Simple declarative builds: a simple, predefined method to make the creation of versioned data images simple, while enabling user/group access controls, data masking and other data engineering functions.
    • Scalable data cloning: database clones are served on demand, with many simultaneous clones served from a single image.
    • Comprehensive database support: the repo supports all common relational, NoSQL, machine learning and file-based data stores.
    • Versioned databases: each image becomes a versioned, immutable DevOps artifact.
    • Deploys equally to all cloud environments: DevOps databases can be deployed and operated on any on-premises infrastructure or cloud.
    • Cross-platform:  DevOps databases can be deployed and operated on common operating system environments such as Windows and Linux.
    • Security features including access management, data masking and encryption: database images easily incorporate access control, data masking and synthetic test data via SQL scripts, batch files or command line tools.
    • Compatible with CI/CD platforms:  DevOps databases can be deployed and operated equally well in multiple CI/CD platform tools such as Azure DevOps, Jenkins and CloudBees.
    • Compatible with containers and container orchestrators: DevOps databases can be deployed and operated equally well in multiple container environments such as Docker, Kubernetes and Red Hat OpenShift.
    • Deliver writeable data at the speed of DevOps: Deliver writable databases in seconds.
    • API for easy integration with DevOps tools: An API is available to enable integration of the DevOps database control plane with other tools.
    • Audit logging: The DevOps database includes a complete audit log of operations.

    Transforming to the New Database DevOps Platform

    A DevOps database platform in an enterprise requires more than simply buying and installing software and telling everyone to use it. With multiple entrenched database platforms already in place, there are practical and political considerations that must be overcome. Introducing any change to a large group of applications in an enterprise can be chaotic, and will often be more costly and take too much time if the changes are not compelling.

    To be sufficiently compelling, the database DevOps platform needs to be affordable, easy to understand, easy to set up and use with a wide variety of CI/CD pipelines. The following will be sufficiently compelling benefits to drive adoption:

    • Versioned, secure database environments or images managed as a DevOps artifact.
    • Images can be built and managed by the DevOps team, without requiring new infrastructure.
    • Multi-DB and multi-TB data environments in seconds.
    • Database environments can be served on demand for a CI/CD pipeline.
    • Lower-level database environment infrastructure is streamlined, with a single VM capable of supporting many simultaneous database environments which drives an immediate cost savings and positive ROI.
    • Data security and governance benefits with versioned database environments, with built-in and auditable security policies.

    What This Means

    Digital transformation is imperative for modern enterprises and organizations to remain competitive. However, the transformations of many enterprises and organizations are seriously impeded by the challenges of integrating databases into their DevOps application pipelines and value streams. A new DevOps database platform can allow the databases to be treated like any other DevOps artifacts that are orchestrated and automated within the DevOps toolchains.

    Suggested resources for automating database environment delivery include Windocks, Cohesity and other storage appliances that provide virtualized (cloned) database environments that can be adapted for DevOps purposes. I want to particularly acknowledge input from Windocks, who has introduced a DevOps data repo that features database virtualization on standard Linux and Windows servers, for versioned data environments and CI pipelines and cloud-native support for data delivery for containers, Kubernetes and conventional instances.

  • Higher Mobile App Stability Begets Higher User Ratings

    Higher Mobile App Stability Begets Higher User Ratings

    In the competitive mobile market, application stability is imperative. Downtime leads to poor user experiences, which stunts growth and revenue. Apps that have poor stability suffer the consequences. In fact, new studies show that just a 1% lower stability ranking can lead to nearly a one-star drop in App Store ratings.

    Bugsnag recently released its 2021 Application Stability Index (ASI) report, Characteristics of Leading Mobile Apps. The study took 260 top-performing mobile apps across industries and reviewed each’s stability and end-user satisfaction. The study found that apps with solid stability tend to rank much higher in the App Store and maintain increased user engagement. The report also demonstrated that developers are pivoting to weekly releases to quickly address bugs, progressing from the bi-weekly standard for software updates.

    Below, I’ll review the specific details of the ASI and the report and consider how stability varies throughout industries. Hopefully, the results here will help other software teams benchmark their app’s performance and release cadence against top-performers within their sector.

    Stability = User Satisfaction

    When measuring uptime and availability, five nines, or 99.999% uptime, is the golden target for most teams. This report measured stability as the percentage of apps sessions that were crash-free. The median across market-leading apps was 99.80%.

    What’s interesting is that apps with more nines in their stability score achieve markedly higher App Store ratings. Apps that scored less than 99.00% had a median rating of 4.15, whereas apps with 99.99% to 100% measured uptime had a median rating of 4.70. The distribution of ratings was extremely wide for low-performing apps, compared to higher average scores for higher stability.

    What do these results say? Users expect uninterrupted sessions. Frequently occurring stability issues can damage the consumer’s opinion of an app, leading to dissatisfaction and harsh reviews. The more stable an app is, the better chance it has to drive consumer success.

    Stability by Industry

    The study also exposed stability differences between industries. B2B SaaS apps ranked relatively high, at 99.85%. This is likely because B2B software must meet service-level agreements (SLAs). Such services have fewer (yet more high-paying) customers to support, the report speculated. Mobile apps directly tied to the exchange of money, such as e-commerce (99.86%), travel and hospitality (99.90%) and financial and banking (99.85%) also ranked consistently high in stability.

    Coming in second were mobile apps in the business-to-consumer (B2C) (99.82%), consumer goods (99.80%) and health and wellness (99.78%) categories. Though these areas require decent availability to remain viable, they may not need such stringent SLAs. In such scenarios, non-stop availability isn’t as directly tied to end revenue.

    Lastly, apps with the worst stability were found in the mobile games (99.71%) and media and entertainment (99.65%) categories. Mobile gaming had the worst ratings of all industries; mean stability equated to over a full day of outage per year. Increased downtime in both categories is perhaps due to more problems with frequent media updates. These areas also tend to have a lower average revenue per user (ARPU), which may affect how teams value ongoing support.

    Deployment Frequencies

    According to the report, highly stable mobile apps tend to release at least once per week, replacing the bi-weekly norm for updates. Nearly all industries are pushing at least four releases per month, aside from consumer goods and travel and hospitality, at 2.5 and 4 respectively. E-commerce takes the cake with a mean of seven releases per month.

    Nowadays, progressive delivery is made possible due to increased emphasis on CI/CD. Therefore, rapid deployment frequencies are the norm. Releasing new versions more quickly can help appease users with new features. It’s also helpful to quickly patch bugs and decrease mean time to recovery (MTTR) for major incidents.

    Users Love Stable Apps

    Throughout the pandemic, digital reliance soared—84% of consumers said applications were a lifeline to normality, found a recent AppDynamics report. In this climate, mobile applications are critical to delivering valuable interactions.

    Yet, user expectations have evolved. Now, it’s readily apparent that stability directly impacts consumer confidence. The ASI findings behoove engineers to edge closer to the five-nines goal. The more nines you have, the better off you are.

    “The results of our second ASI report highlight the need for better proactive error monitoring and stability management to help engineering teams build healthier apps that deliver superior customer experiences,” said James Smith, SVP of the Bugsnag Product Group at SmartBear.

    It’s good to reiterate that this study examined a handful of leading apps from each industry. So, these scores shouldn’t be construed as inclusive of the entire app marketplace, only as benchmarks for the top mobile app performers.

  • CloudTruth Acquires Tuono to Advance Configuration Management

    CloudTruth Acquires Tuono to Advance Configuration Management

    CloudTruth, a provider of a unified configuration management platform, today revealed it has acquired Tuono, a provider of a cloud secrets management platform, as part of an effort to make it simpler to secure infrastructure provisioned using code. Terms of the deal were not disclosed.

    Greg Arnette, CloudTruth CEO, said misconfigurations are rife across cloud computing environments. IT organizations now need a self-documenting approach to managing configurations as the number of cloud services that organizations can employ continue to multiply. The CloudTruth platform will automatically keep track of all configuration changes made to an IT environment, Arnette said.

    The rise of Kubernetes and microservices is making things even more challenging, introducing a range of additional opportunities to misconfigure cloud platforms and applications.

    Fresh from raising $5.25 million in seed funding, Arnette said one of the least-appreciated aspects of the configuration challenge is how dependent organizations are on tribal knowledge that gets shared unevenly across DevOps teams. The lack of a centralized repository for managing configurations makes it challenging to onboard new members to those DevOps teams, he added, resulting in more opportunities for mistakes to be made.

    Tuono adds a cloud-native secrets management platform that can be deployed across multiple cloud services. The goal is to provide a configuration management platform that functions as a metadata wrapper compatible with configuration tools such as Terraform or CloudFormation from Amazon Web Services (AWS). That approach reduces the cognitive load on DevOps teams that would otherwise have to remember how and why each service is configured the way it is, said Arnette.

    Arnette added that an additional goal is to enable DevOps teams to put guardrails in place that reduce the opportunities for misconfiguration errors to be made while continuing to enable developers to build and deploy applications quickly. Each organization will need to decide where to strike a balance between those competing agendas, noted Arnette.

    The challenge organizations are wrestling with today is just how vulnerable software supply chains are—as a series of cybersecurity attacks have made all too apparent. Organizations are adopting DevSecOps best practices to better secure those supply chains. However, the rate at which DevOps teams can come up to speed on security isn’t fast enough to secure applications that are about to be deployed. At the same time, there are potentially hundreds of applications deployed in cloud platforms with varying degrees of misconfigurations. Cybersecurity teams are now being asked to review how well those applications are configured as part of an effort to address the security of the entire software supply chain.

    It’s not clear if a backlash against DevOps, in general, is in the making as cybersecurity teams review application development and deployment practices. There undoubtedly will have to be adjustments made to those processes, even as most organizations realize just how dependent they are on software. The issue is that deploying more insecure applications faster is, at the end of the day, counterproductive.