devopsy.kinsta.cloud

Tag: software as a service

  • Mirantis Adds Modeling Tool to Configure Private Cloud

    Mirantis Adds Modeling Tool to Configure Private Cloud

    At the Open Infrastructure Summit conference, Mirantis today unfurled a software-as-a-service (SaaS) application through which IT administrators can employ modeling tools to configure private clouds based on either OpenStack or Kubernetes.

    Boris Renski, chief marketing officer for Mirantis, said rather than having to manually configure a private cloud for an on-premises IT environment using YAML files, the Model Designer for Mirantis Private Cloud enables IT administrators to configure a private cloud using modeling tools they access via a graphical interface (GUI). The Model Designer is scheduled for general availabilility in May.

    That approach then makes it feasible for IT administrators with little to no programming expertise to quickly spin up private clouds within the context of a DevOps environment using a set of declarative tools, added Renksi.

    Those tools also enable IT administrators to specify the degree of configurability they require. A basic configurability level automatically populates most of the cluster settings to a default set of pretested values. The most advanced “ultraviolence” configurability setting enables IT administrators to adjust virtually every aspect of their on-premises cloud. The resulting configuration models are then fed into DriveTrain, which is the automation framework that Mirantis provides within Mirantis Private Cloud.

    Renski said requiring IT administrators to master all the nuances associated with managing YAML files to stand up a private cloud is one of things holding back adoption of both on-premises private clouds and the best DevOps practices that should be relied to mange them. Most organizations that want to make the transition to DevOps clearly want to be able to manage infrastructure as code in much the same way public cloud service providers do today. The challenge is, the learning curve associated with achieving that goal is simply too high for the average IT administrator, he said, adding a modeling tool made available as SaaS application will make it possible for even mere IT mortals to easily spin up a private cloud within an on-premises IT environment.

    Both OpenStack and Kubernetes suffer to varying degrees from often being too complex for the average IT organization to set up. Because of those complexity issues, adoption of both platforms often is limited to IT organizations that have advanced IT skills. But as the deployment processes surrounding both platforms become more automated, it’s probable the number of organizations adopting either platform will increase. At the same, IT organizations that do embrace either platform more likely will spin up more instances once they no longer have to rely on a cumbersome manual set of processes.

    Of course, setting up a private cloud based on either OpenStack or Kubernetes is only the beginning of the IT challenge. Once all those private clouds are deployed, IT organizations need to acquire the tools and expertise required to manage them on an ongoing basis. In fact, one of the things IT organizations should consider in the age of the private cloud is the level of integration of the tools from vendors they intend to rely on to set up and then manage a private cloud.

    — Mike Vizard

  • Bridging the Gaps in SaaS to Meet Business Needs

    Bridging the Gaps in SaaS to Meet Business Needs

     Today, software as a service (SaaS) is a mainstream model for application consumption, with industry-specific and business process-focused offerings increasingly available. Flexibility, reduced time to market and cost benefits are the top advantages and selling points of SaaS offerings.

    SaaS-powered business processes allow businesses to provide feedback in real time, thus enabling a smooth change management process. The agility of such applications also generates higher user-community satisfaction and engagement. As a result, Gartner’s recent forecast predicts the SaaS market size will grow at a compound annual growth rate (CAGR) of 18 percent in the next four years, reaching $127.6 billion USD in 2021.

    Despite the apparent benefits, SaaS models carry their own set of disadvantages, especially when the application impacts key underlying business processes. These processes are typically unique to an organization and are seldom available out-of-the-box (OOB). The specific changes an organization needs often proves a solution inadequate and in need of major customization and permissible extensions.

    If the design of the solution is stretched too far from the originally intended logic of the software, it can cause major disruptions to future upgrades of the SaaS solution. An alternative to customization is simplifying business processes so they fit into OOB features. However, business users resist adopting a new simplified process, particularly when the process in question is a perceived differentiator. At the same time, it is not in the best interest of vendors to modify their design, catering to the requirements of just a few organizations.

    The Crucial Role of Architecture

    Business process architecture must be harmonized with solution architecture. That is why architecture plays an essential role in SaaS implementation. Business process architects need to quantify the criticality of business processes and leverage the insights to build consensus among stakeholders, which include business users, SaaS providers and IT departments. The solution architects, on the other hand, should ensure alignment between business process requirements, downstream enhancements to an offering’s capabilities and future readiness of IT to handle upgrades.

    Architects now empowered with business process and solution architecture should identify business KPIs that drive SaaS adoption and measure the impact on process performance. Gap and impact analyses tools can be used by architects to identify gaps between business requirements and OOB features of SaaS products. These analyses tools will result in a list of customizations, which need to be further evaluated.

    SaaS Evaluation Framework

    Each customization made to the SaaS application should be assessed on two dimensions:

    1. Potential business impact/criticality: When evaluating the potential business impact, architects should start by identifying sources of differentiation. Differentiation may arise from enhancement in customer-facing capabilities or improvement in operational efficiency—or both. Mapping measurable quantitative outcomes such as CSAT ratings, turnaround time, etc. can help define potential differentiation.
    2. Ease and cost of customization: Overall cost of ownership should serve as the primary way to evaluate the ease of customization, and right-size the trade-off between ease of implementing customizations with the ease of maintaining the solution. While the parameters to measure ease and cost of customization need to be defined, considerations include design types, the time and effort required for development, maintenance and upgrading activities (e.g. plug-in/script development).

    The above proposed assessment must also identify the following:

    1. Impact of not having requested features.
    2. Technical challenges in configuring/customizing the solution to meet each requirement.
    3. Ability to upgrade SaaS application without having to reapply customizations.
    4. List of actions to bridge identified gaps between proposed SaaS solution and existing process requirements.

    As displayed in the graphic above, customization needs to be treated differently based on which quadrant it gets mapped to.

    Appropriately Prioritizing Customizations

    Customizations that are easy to implement but don’t yield any measurable benefit to the business should be avoided as much as possible to eliminate risk, save effort and allow investments elsewhere.

    Similarly, customizations that are difficult to implement and carry no clear benefit or impact on outcomes, must be avoided. Instead, IT will have to convince the business to adopt OOB processes.

    On the other hand, critical customizations that are easy to implement and maintain should be shortlisted for further steps. Since there is a clear business case warranting customization, architects should ensure that the design approaches are recommended and supported by the vendor.

    Must-have business functions requiring difficult customization must be carefully examined. Consider the following questions: Will it still provide perceived time-to-market advantage? Will it increase overall cost of development and ownership? Will it impact scalability, upgradability and integration capability?

    In some cases, the SaaS provider may have feature enhancements in its pipeline that would help implement these must-have requirements. If so, the IT team should collaborate with the provider, influencing and defining upcoming product features.

    If that’s not an option, an alternative is to implement critical functions outside the SaaS solution and then connecting through well-designed back- and front-end integrations. For example, some SaaS providers allow customers to build composite apps on their platform as a service (PaaS). These apps can provide differentiated features without having to change the core SaaS solution. However, keep in mind that PaaS apps will need real-time integration with SaaS apps to achieve this.

    As explained above, not all business processes deem a customization of the SaaS solution. A structured framework should be used to classify which customizations will play a crucial role in any organization’s SaaS adoption journey.

    All customizations should be reviewed and approved by the program steering committee consisting of stakeholders from IT, business leadership and the SaaS provider. All parties involved need to have a clear understanding of why the customization is critical—that means business stakeholders need to provide justification for why a workaround or process change is not viable. Similarly, IT and the SaaS vendor need to articulate a plan of action and a road map for upgrades. In doing so, businesses will reap the full benefits of moving toward SaaS.

    — Monoj Baruah

  • Red Hat Aims to Push IT Management to the Cloud

    Red Hat Aims to Push IT Management to the Cloud

    Red Hat at the Red Hat Summit 2018 conference this week showed a technology preview of an instance of Red Hat Insights, a predictive analytics IT management application capable of identifying operations issues before they become a problem, running as a software-as-a-service (SaaS) application.

    The instance of Red Hat Insights will be extended to apply analytics to any infrastructure platform. Red Hat plans to eventually make the rest of its IT management portfolio available as a cloud service.

    Joe Fitzgerald, vice president and general manager for management at Red Hat, said the goal is to enable management of virtual machines, container, infrastructure-as-a-service and physical servers all from a single pane of glass.

    Cost analytics also will be embedded in those services, adds Fitzgerald. Cost is now a much bigger issue because cloud service providers bill customers based on actual consumption. Previously, a virtual machine left running on an on-premises server might result in someone being yelled at, but no additional cost, notes Fitzgerald. Now, however, if an IT organization doesn’t turn off those virtual machines, it will end up paying more.

    Fitzgerald noted that management of IT operations is becoming increasingly automated. Red Hat is now adding integrations with the agentless Ansible framework it acquired in 2015 at rate of 50 a week. There already  are 1,600 integrations with Ansible. He said the fact that Ansible presents IT operations teams with a declarative approach to automating IT using YAML files makes IT automation much more accessible. Other frameworks require IT operations teams to learn how to program, which becomes a significant barrier to adoption, but YAML files allow IT operations teams to make use of familiar shell scripts.

    Many organizations now are moving up the IT management curve as applications become more distributed, Fitzgerald said. Every platform they have comes with its own management tools. But the need for a control plane through which multiple platforms can be centrally managed is now becoming more evident, he said, especially as IT organizations realize they will be running many different types of platforms for many years to come.

    Other benefits to shifting IT management into the cloud is that the move eliminates the need to deploy a local server just to run IT management software and all updates to the IT management platform are provided by the applications provider.

    Obviously, Red Hat is not the only IT vendor building a centralized, cloud-based approach to managing distributed computing environments. But as Ansible becomes more widely adopted, the opportunity arises for Red Hat to engage in a broader IT management conversation with IT organizations.

    Most enterprise IT organizations are rapidly approaching something of an IT management crisis. Each platform adopted creates yet another silo that makes adopting integrated DevOps processes even more challenging. While most organizations are not likely to abandon the management tools from the vendors that built those platforms, IT organizations are demanding thet underlying infrastructure exposes an application programming interface (API). In fact, it’s the proliferation of all that software-defined infrastructure that now makes it feasible to centralize the management of IT in the cloud.

    — Mike Vizard

  • SolarWinds Aims to Democratize Monitoring

    SolarWinds Aims to Democratize Monitoring

    In a move that has the potential to significantly expand the number of organizations embracing DevOps, SolarWinds announced it has expanded its IT management cloud service to include an integrated application and infrastructure monitoring offering dubbed AppOptics. Pricing for AppOptics starts at $7.50 per host per month.

    In addition, SolarWinds has updated Papertrail log management software to make searches faster and provide new visualization tools and the ability to resolve more complex problems such as application server errors and slow database queries. The company also updated Pingdom, a monitoring tool that can now provide views specific to a user, website or specific performance issues.

    Christoph Pfister, executive vice president of products for SolarWinds, says AppOptics should be make it much less expensive for organizations to embrace DevOps. Many organizations get caught up in a chicken-and-egg debate over whether to acquire tools before developing processes or vice versa. AppOptics renders that issue largely moot by making the cost of employing an integrated set of tools for monitoring infrastructure and applications nominal, says Pfister. That level of integration is now required to address digital business initiatives where the focus is more on the outcome than any one IT event, adds Pfister.

    Pfister says SolarWinds is the only provider of a software-as-a-service (SaaS)-based set of monitoring toils that support multiple programming languages, which he notes creates yet another opportunity for DevOps teams to reduce costs.

    AppOptics includes support for auto-instrumentation, distributed tracing and host agent software. That tracing software is based on technology SolarWinds gained when it acquired Librato. Adding instrumentation to any application can be accomplished using a single line of script, says Pfister. The host agent support is achieved using Snap and Telegraf plug-ins to monitor systems.

    By making it easier to add instrumentation, Pfister says SolarWinds expects the number of applications actively being monitored will increase substantially. Historically, only a small percentage of applications deployed in an enterprise are actively monitored. Pfister notes that a much higher percentage of new applications being developed are “systems of engagement,” which require much higher levels of instrumentation to gauge acceptance by end users, and not “systems of record.” Gartner says that only 5 percent of organizations today have implemented digital experience monitoring (DEM), a number it forecasts will rise to 30 percent by 2020.

    At a $7.50 per host per month price point, AppOptics should go a long way to commoditizing DevOps tools. That should not only spur more adoption, but also could force a wave of consolidation across a crowded category of monitoring tools as profit margins get squeezed. In many instances, it’s also likely that monitoring increasingly will be bundled with other tools and services as vendors aim to compensate for monitoring becoming a commodity by selling it alongside higher margin products and services.

    Long term, it’s apparent that cost is increasingly being removed as a factor in the DevOps equation. Not every organization is going to able to master every DevOps tool available. But when it comes to monitoring, going forward there should be no financial excuse for failing to have at the very least some minimal level of DevOps capability.

    — Mike Vizard

  • Cloud Services Demand Security Up the DevOps Stack

    Cloud Services Demand Security Up the DevOps Stack

    In the era of soaring use of public cloud by companies, software delivery is moving away from an on-premises install approach to a cloud-based subscription model through software as a service (SaaS).

    Customers expect a lot when it comes to SaaS products and services. Whether they are investing in SaaS-first offerings or shifting workloads to cloud-based providers, companies no longer have upfront costs for hardware and related software or a reliance on costly labor to install, manage and secure it. They expect software that is easy to launch, upgrades that are unobtrusive and feature-rich and limitless scaling to meet their changing business needs.

    When it comes to security, the cloud-based subscription model significantly changes the paradigm of how software security should be treated. Fortunately for many cloud providers, customers trust that a strong foundational security and privacy posture has been built into to the service by design. Preserving that trust requires a healthy tension of shared responsibility between the security teams demanding it and the cloud providers offering it. A new paradigm shift requires a deeper acknowledgement that an emphasis of the security problem “up the stack” to the application layer is needed.

    For security teams, ensuring the protection is built in from the beginning and moves dynamically in lockstep with the workloads requires a much closer partnership with application developers and DevOps teams. This ultimately leads to a richer understanding of the business applications by security teams, creating a more cooperative business-aware and security-minded culture. Getting there will help reduce the tension and improve the overall delivery of secure cloud services regardless of where you sit in the cloud provider/consumer ecosystem and ultimately enables value creation to the business. To get there, a strong partnership must be fostered.

    There are obstacles to moving up the stack. In most companies, the reality is that many security teams are not well-aligned to keep up with this change while the business continues to make cloud-based investments, making the problem worse. Security’s comfort zone seems very much still focused on perimeter defense, but this emphasis isn’t optimally aligned to a cloud-first future. Even when forward-leaning security shops realize a need to change, they often get pushback from app developer teams because security reviews can delay deployment and security tools create “noise” and false positives for app developers. Also, traditional security tools often do not work well in cloud environments.

    Interestingly enough, the No. 1 concern of app developers is preventing data breaches and cyberattacks, a survey of 500 developers and development managers by Veracode found. Less than one-quarter of developers said meeting customer or regulatory compliance is their top concern, while 21 percent said meeting budget and delivery schedules is their top concern, and 19.4 percent said delivering secure code to pass internal audits is a priority. Furthermore, app developers who work with security teams get “major and tangible business and technical benefit,” according to a survey of 150 security and app development pros conducted by Forrester Consulting. Almost all of the collaborators said that working together leads to major or moderate benefit in customer satisfaction.

    Respondents said the more frequently they collaborate, the better the results, “including improved customer satisfaction, business/IT alignment, quality and frequency of releases, and the rate of innovation at their firms.”

    By overcoming barriers to collaboration, app developers and security teams can leverage this knowledge to improve their approach and also come to the table with solutions aligned at moving up the stack. First, they can perform code analysis to uncover vulnerabilities early in the app development process. Second, they can work on stronger runtime protection once the SaaS application is deployed. Code analysis can be used to make runtime protection better, and runtime data can be used to improve code analysis. This creates a continuous improvement loop between the two and both teams can work on code analysis and runtime protection together.

    To achieve this continuous improvement loop, companies must work to break down traditional work silos that exist because of a mismatch in expectations. App developers, measured for speed, need to receive security information accurately, early and with sufficient context to correct problems during software development. Security pros can benefit by installing security tools in production that understand the security needs of their applications, as opposed to tools that require security pros to write rules, tune the tool and then deal with large number of alerts.

    The goal is to fix software mistakes, weaknesses and vulnerabilities at the beginning of the development process rather than after deployment, when liability, revenue and reputational risks are the greatest. It is also important to realize that achieving zero defects in source code is a noble but difficult-to-achieve goal. Instead of focusing on extremes, the goal should be to establish a continuous improvement logic in CI/CD (continuous integration/continuous deployment), where bugs are identified, some are fixed and the remainder have fast and accurate runtime protection.

    This shift in thinking and processes will give companies fewer security worries and enable them to more proactively embrace a SaaS-first mentality with higher confidence and trust levels. Companies will reap the financial benefits that come with strengthened industry reputations for rapid innovation capabilities and improved levels of software security.

    About the Authors

     Manish Gupta is founder and CEO of ShiftLeft Inc. He is a 20-year veteran of the security industry and has led product development, management and strategy at FireEye, Cisco Systems, Intel, McAfee and Redback Networks.

     

     

    Craig Rosen is vice president and CISO at AppDynamics. He has held leadership roles for more than two decades in the security industry, including at FireEye, Pacific Gas & Electric, TDI and CGI.

  • CA Technologies Extends DevOps Push

    CA Technologies Extends DevOps Push

    At its CA World 2017 conference this week, CA Technologies moved to tighten the integration between the various elements of its DevOps portfolio acquired over the last year and unveiled CA Digital Experience Insights, an analytics-infused monitoring tool delivered via a software-as-a-service (SaaS) model.

    The company also announced an instance of the CA Microservices Gateway that allows the API management platform to be deployed as a Docker container. Earlier this week, CA Technologies launched a beta release of Fastrack.io, a service for monitoring Kubernetes clusters based on machine learning algorithms and embedded in an instance of the open-source Prometheus container monitoring service.

    The company is also adding CA Virtual Test Data Manager, a tool that makes it simpler to create copies of large data sets for testing purposes, and CA Service Virtualization Community Edition and CodeSV, a plug-in that enables DevOps teams to invoke service virtualization from within their integrated development environment to mimic external services without having to connect to an actual instance of those services running in a production environment.

    Additionally, CA Technologies announced it has integrated CA Veracode security testing software with CA Automic IT automation platform, and announced general availability of BlazeMeter API Test, a SaaS-based API testing tool, and CA Continuous Delivery Director SaaS, a service that integrates the DevOps toolchain.

    Aruna Ravichandran, vice president of DevOps product and solutions marketing for CA Technologies, says each of these offerings are part of a larger company effort designed to enable organizations to set up their own software factories. Now that more organizations have come to realize their ability to differentiate themselves depends on custom software, many of them want to be able to acquire all the integrated DevOps tools required to achieve that goal from a single vendor, Ravichandran says.

    CA Technologies is making a concerted effort to link the need to create a software factory as a prerequisite for driving digital business transformation at scale. To achieve that goal, she says, control over IT operations is continuing to shift to the left as developers become more accountable for the entire application experience. Offerings such as CA Digital Experience Insights make it simpler for developers to holistically manage those end user experiences by infusing predictive analytics and machine learning algorithms coupled with improved data acquisition techniques in a single service, Ravichandran says.

    CA Technologies clearly wants to become a DevOps force to be reckoned with. In the last two years it has acquired Blazemeter, Automic, Veracode and Runscope. Prior to that, the company acquired Rally Software, Nolio, Grid Tools and Layer 7 Technologies. From here it’s likely CA Technologies will continue to expand its portfolio by acquiring companies while tightening the integration between the various code bases that make up its DevOps portfolio.

    The company’s stated goal is to provide a suite of DevOps tools and services that are too compelling to ignore without forcing IT organizations to consume a product or service they don’t want by maintaining open interfaces across the portfolio. The degree to which CA Technologies can succeed in that effort remains to be seen. But there’s no getting away from the fact that the company has now assembled a formidable DevOps arsenal of products and services.

    — Mike Vizard

  • SAP Adds SDK to ERP Cloud Service

    SAP Adds SDK to ERP Cloud Service

    When most IT organizations think about DevOps it’s usually within the context of custom application development. But thanks to the rise of application programming interfaces (APIs), packaged applications are now becoming a much bigger factor. SAP, for example, just made available a software development kit (SDK) for SAP S/4HANA Cloud, an instance of its ERP software hosted in the cloud.

    Christian Pedersen, chief product officer for SAP S/4HANA Cloud, says the company is encouraging developers to integrate SAP and custom applications. The company is unable to address every potential use case on its own, he says, and it doesn’t make much sense for developers to reinvent functionality that already is an API in a SAP packaged application. The goal should be to deliver a unified application experience made up of packaged and custom components that all are accessed via a common user interface experience.

    That approach, he says, will be critical as SAP continues to invest in advanced machine learning algorithms and digital assistants. Rather than having to develop those technologies themselves, Pedersen says it’s going to be a lot more practical for many developers to leverage capabilities that SAP will expose via APIs.

    SAP’s approach to custom applications is unique in that it makes available a separate SAP Cloud service based on the platform-as-a-service (PaaS) environment developed by the Cloud Foundry Foundation and the Kubernetes cluster platform now overseen by the Cloud Native Computing Foundation (CNCF). The best part about the SDK, says Pedersen, is that it includes sample code that developers can reuse in their applications. As far as DevOps is concerned, SAP is not driving any specific approach, preferring to work with a variety of continuous integration and continuous delivery (CI/CD) platforms.

    Some developers have historically viewed SAP and other providers of packaged applications warily. There is a tendency for vendors that sell packaged applications to continually expand the footprint of their software. SAP isn’t promising not to expand the footprint of its applications further, but, Pederson says, when it comes to crafting a unified application experience aimed at specific use cases, the developer community is essential.

    The biggest challenge associated with combining PaaS environments with software-as-a-service (SaaS) applications is getting the updates to the respective environments synchronized. DevOps teams don’t have any control over when a SaaS application provider chooses to roll out new capabilities. In many cases, the pace at which the SaaS application provider delivers those updates often sets the pace for the whole DevOps teams. In some cases, IT organizations will prefer to run applications on-premises just to exercise more control over the upgrade cycle.

    Whatever the approach, there’s clearly greater need for more DevOps sophistication now that packaged applications have essentially become back-end services that are invoked as a service via an API. The first order of business toward achieving that goal, however, may be informing the owners of those applications they are now part of a much larger ecosystem that needs to be considered every time anyone wants to update a module or add a new service.

    — Mike Vizard

  • Software Security is an Engineering Problem

    Software Security is an Engineering Problem

    We live in a world where those who sell products are generally held accountable for defects. Automobile manufacturers, pharmaceutical companies and toy makers are among the businesses that have been handed fines and tarnished reputations for distributing items that were later deemed ineffective or dangerous.

    One notable exception to this “consumer first” ethos is the traditional shrink-wrapped software world, where responsibility for product problems is hazy. The vendors that develop and sell software and the customers who purchase and install that software are in a constant battle to shift security liability. The vendors strive as best they can to reduce and remove product vulnerabilities and offer secure configurations while customers deploy, configure and operate the software in very different environments, with very different configurations, which can produce very different security outcomes. Because no customer can (or should) assume receipt of 100 percent vulnerability-free software, they must always take on the primary burden of protecting the environments where that software lives to offset the risks—which typically falls to the customer’s IT and security teams.

    Although there are excellent arguments for both sides, the current situation leaves both parties wanting—and needing—a higher level of assurance in both the development and runtime settings.

    Software Delivery Has Changed (Along with Security Responsibility)

    The good news for software customers is that software delivery is rapidly moving away from an on-premises install approach to a cloud-based subscription model where applications are delivered via the internet. Upfront costs for hardware and software, as well as the expense of personnel to install and manage that software, are replaced with business-friendly, predictable, subscription-based operational costs. Software is easy to launch, upgrades are uncomplicated and scaling to meet changing business needs is simple.

    Customer expectations are high for software-as-a-service (SaaS) solutions. Purchasers demand an elevated level of innovation and want new features more often. They assume built-in support of global information security and privacy regulations such as the European Union’s General Data Protection Regulation (GDPR) and various U.S. regulations, including the Health Insurance Portability and Accountability Act of 1996 (HIPAA) and PCI Digital Security Standard (PCI DSS). SaaS customers also expect the vendor to take on larger responsibility for any potential software vulnerabilities that might negatively impact the customer’s data and operation.

    The new reality is that deploying software in the cloud significantly changes the paradigm of how software security should be treated at the vendor level. This means companies now have to think critically about security as an engineering problem as the balance of the liability burden shifts focus to the cloud provider’s engineering practices to ensure constant delivery of a secure and trusted cloud service, rather than just secure software.

    Now is the Time to Rethink Software Security

    Cloud-based application delivery brings together under a single company umbrella the ones that make the software and the ones who run the software. Informing software development of runtime behavior and vice versa can have significant advantages in enhancing the overall security of the software by offering a closed-loop system. In such a perspective, the rapid pace of software releases work in favor of enhancing security.

    Shifting security to an all-around engineering responsibility requires the elimination of traditional work silos. Geared-for-speed developers must receive precise information early, allowing them to correct security problems during the initial coding process. DevOps team members also must assume security responsibilities. And security engineers who understand the attacker mindset, security risks and compliance requirements must provide guidance at all points in the software development process.

    Change is never easy in any organization, so transforming disconnected teams into one in which security is an across-the-board responsibility is difficult. Managers must be careful to not alienate team members who already have full plates. And although we’re starting to see some shifts in the educational model to one in which professionals are taught early on how to seamlessly integrate coding and security, we have a long way to go.

    While we wait, the most effective way to overcome the chronic problem of heavily siloed teams is to provide the entire software engineering team with a means to quickly identify issues between software development, its deployment and runtime across all the components. These tools must give users the ability to:

    • Scan and provide real-time analysis that integrates source code analysis and its runtime behavior. After all, they are two sides of the same coin;
    • Obtain accurate and full visibility into the security impact of changes from build-to-build;
    • Ease the audit analysis process;
    • Reduce the number of false positives; and
    • Allow developers, DevOps, and Security to collaborate to enhance the security of the environment.

    The goal? An ability to fix software mistakes, weaknesses and vulnerabilities at the beginning of the development process instead of post-deployment, when liability, revenue and reputational risks are the greatest.

    Consolidating today’s siloed security practices into an integrated engineering effort is the only way to ensure the appropriate level of security at the appropriate time in today’s fast-moving cloud-based software industry. This sort of shift in thinking and processes will give customers less security worries and better products. Development teams will become more effective and efficient. DevOps will have real-time visibility into how each release impacts the infrastructure. And Security will know how each release impacts both security and compliance requirements. SaaS companies will reap the financial benefits that come with strengthened industry reputations for rapid innovation capabilities and high levels of software security. It’s a win-win-win for everyone.

    About the Authors

     Manish Gupta is founder and CEO of ShiftLeft Inc. He is a 20-year veteran of the security industry and has led product development, management and strategy at FireEye, Cisco Systems, Intel, McAfee and Redback Networks.

     

     

    Craig Rosen is vice president and CISO at AppDynamics. He has held leadership roles for more than two decades in the security industry, including at FireEye, Pacific Gas & Electric, TDI and CGI.

  • SaaS-Powered FlightPartner Fueled by DevOps

    SaaS-Powered FlightPartner Fueled by DevOps

    Private jet charter company FlightPartner is reaping the benefits of DevOps to build a powerful software-as-a-service (SaaS) offering to keep its customers flying high with no delays.

    “FlightPartner does not own any aircraft but rather facilitates the travel needs of clients by offering air charter brokers (agents to the client) access to a global network of private jet charter availability,” says Douglas Schmohl, CEO and founder of FlightPartner. By acting as a global distribution network (GDN), FlightPartner enables access to real-time availability of private jets.

    What TravelPort is to airline seat availability, FlightPartner is to private jet availability, Schmohl says.

    FlightPartner’s cloud-based SaaS manages data exchanges and transactions through a web browser as a web-based service, requiring no client software installs for the brokers or operators. The service uses Angular.js, a “structural framework for dynamic Web apps” to pass data from the browser to a PHP back end. A database and integrated systems back end builds real-time pricing quotes for available private jets, while the payment mechanism supports search, booking and payment, completing the transaction, Schmohl says.

    FlightPartner uses a Laravel open-source PHP framework, which was created by Taylor Otwell and was originally targeted to developing Web applications following the model-view-controller (MVC) architectural pattern. “This framework allows for rapid development, testing and deployment of our SaaS solution,” Schmohl notes.

    SaaS Technical Challenges

    Schmohl and company endured some technical issues as they built FlightPartner software and worked to raise it to the skies where it would eventually soar. Schmohl was committed to following the lean startup practices of Eric Reis, author of “The Lean Startup,” which redefined the roadmap for a startup tech company, Schmohl says. According to the book, one of the first steps in approaching a new business as a lean startup is to try to float a “minimum viable product,” or just enough product or service to test the market demand for it. “This was nearly impossible for us due to the complexity of the air charter marketplace,” he says, so Schmohl had to invest in a more technically developed product rather than a simple solution.

    In the private jet charter industry, with so much change, so many variables, so many players needing access and so many systems that FlightPartner would need to access, a minimum viable product still necessitated numerous external integrations and APIs. “Developmental collaboration to achieve this was difficult at best and developers often pushed code to production only to create more issues with each deployment,” Schmohl says.

    A second technical misstep—and in the absence of formal development structure—Schmohl’s team wrote code to solve specific functional problems one by one. However, the team found that a method for developing one function would conflict with a different method that was used to create another function, and so on. “The constant patching of the front and back end consisted of whatever worked. This code became challenging to manage and scale,” he says.

    Because of these two technical challenges, FlightPartner’s attempts at a minimum viable product and at following a lean startup approach soon were tangled in a mess of spaghetti code and unmanageable methods, Schmohl says.

    FlightPartner Development Pipeline

    Today, development at FlightPartner is much improved. The SaaS and its components start with a local build that the system pushes to a development server in AWS. FlightPartner developers use SourceTree, a Git client and the Git versioning system to manage software versions. FlightPartner uses quality assurance to manage development and to test code, and developers fix errant code and deploy it to AWS using Elasticbeanstalk. “This enables rapid builds and continuous deployment,” Schmohl says.

    Using a DevOps approach to development brings structure to an otherwise-highly dynamic marketplace. “Offering a SaaS solution as a marketplace presents challenges unlike a typical marketplace. Our inventory (aircraft) is fluid in that it moves often and the price changes depending upon location. This operational challenge translates to numerous and constant development with changes in software functionality,” Schmohl notes.

    These are the operational needs that drive software requirements; the developers’ goals increasingly are to meet those requirements so the software seamlessly supports operations. Development uses a priority status to identify and escalate the builds that are most critical to continued, smooth operational activity.

    Results

    FlightPartner’s development process has created a workflow process that minimizes the resources necessary to achieve operational results. Thanks in large part to DevOps and the cloud-based SaaS system, FlightPartner’s GDN has aircraft available for charter in six of the seven continents, including 35 percent of available aircraft located outside the United States, says Schmohl.

  • SaaS: Building Tools for the DevOps-Minded

    SaaS: Building Tools for the DevOps-Minded

    DevOps, Continuous Delivery, Continuous Integration and Continuous Testing are no longer just methodologies and development strategies — they’re all a part of a growing economy within the tech industry.

    Great Software-as-a-Service (SaaS) companies such as Chef, Docker and New Relic have done an amazing job of spotting the trends early and building their tools and services around a new wave of development processes. Chef and Docker alone have reportedly raised nearly $250 million, and New Relic went public in 2014.

    In fact, this very website is another example of how impactful these new development practices are — as several specialized news outlets have been born out of these revolutionary development strategies. So, not only has the DevOps methodology helped developers create better products, faster; but the process has opened opportunities for technical experts to share their experiences on sites like this, e-books, webinars, conferences and any other way people communicate.

    On devopsy.kinsta.cloud, you’ll see the best articles on the web discussing how DevOps is defined in different organizations, why Fortune-500 companies are shifting old practices toward CD and the best practices of CI from industry experts.

    In the race to be the most DevOps-friendly solution — no matter the niche — hundreds of startups have been founded and funded, which has only enhanced the toolboxes of thousands of developers. You’d be hard-pressed to find a good SaaS company that doesn’t offer integration with Jenkins CI, TeamCity or Chef, and that’s because not only should a SaaS product solve an important problem, but it should have minimum disruption of your current development process.

    With all that in mind, Continuous Testing is one of the most exciting spaces in technology today. Continuous Testing is a process that aims to synchronize testing and QA with dev and ops, which ultimately yields better products more quickly.

    There are several factors that make Continuous Testing successful in a team’s software development lifecycle — such as open-source collaboration solutions, test automation APIs and tools to track the historic performance of applications .

    With the release of Load Impact Version 3.0, the global performance and load testing SaaS company has announced its latest feature that fits right in with the DevOps mindset: Performance trending.

    Performance trending allows users to plot runs of the same test over time. That gives companies a clear view into data that locates patterns of performance degradation or improvement in order to easily validate code and infrastructure changes.

    In the spirit of Continuous Testing, DevOps, CD and CI — performance trending improves users’ ability to gain both a low-level and high-level view into the performance of their systems. And with the increased number of tests run by DevOps professionals, performance trending yields valuable information for companies concerned with their application performance — which should be everyone.

    Between devopsy.kinsta.cloud and plenty of great conferences and meetups around the world, it’s safe to say this economy of DevOps-minded tools will only continue to grow in the coming years.