devopsy.kinsta.cloud

Tag: cloud services

  • 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.

  • IBM Adds Cloud Foundry PaaS to Cloud Private

    IBM Adds Cloud Foundry PaaS to Cloud Private

    As IT organizations are being asked to provision and support an ever-growing number of platforms, they increasingly require an approach that abstracts away as much of that complexity as possible. With that goal in mind, IBM created IBM Cloud Private, an on-premises platform that automates the deployment of a private cloud based on Kubernetes container orchestration software. This week, IBM announced it is extending the reach of IBM Cloud Private to include support for the open-source Cloud Foundry platform-as-a-service (PaaS) environment.

    IBM Cloud Private is designed to be deployed on top of virtual or physical servers, including instances of hyperconverged infrastructure based on software from Nutanix. Michael Elder, an IBM distinguished engineer for IBM Cloud Private, says IBM has developed tools for automating the provisioning of not only underlying infrastructure, but also containerized and legacy versions of IBM middleware such as IBM DB2 databases, the Open Liberty Edition of WebSphere application server and IBM Microservice Builder. In addition, Elder says IBM Cloud Private can be employed to deploy a variety of open-source databases, including MongoDB and PostgreSQL.

    Also available for an additional fee with IBM Cloud Private are a plethora of DevOps tools including APM, Netcool, UrbanCode, Cloud Brokerage, Jenkins, Prometheus, Grafana and ElasticSearch. Regardless of the platform employed, IT organizations should be able to apply a consistent set of DevOps processes to manage either Kubernetes or Cloud Foundry, Elder says.

    IBM is also addressing security issues by including Security Vulnerability Advisor to scan containers and an ability to encrypt all data in flight.

    Elder says many IT organizations will deploy 12-factor applications on a PaaS environment alongside containerized applications running on Kubernetes. IBM Cloud Private is designed to provide a common management framework for managing both environments. However, IBM is not extending that management framework to the IBM public cloud. Elder says the company determined that attempting to create a common management framework for both would result in too much complexity, especially for administrators of public cloud services that require a much more streamlined user interface experience.

    Most IT organizations could, of course, craft their own private cloud. IBM Cloud Private simplifies that process by providing all the pieces required under a common management framework. Rather than spending months putting those elements together, IBM is making a case for an integrated platform that enables IT organizations to concentrate more of their efforts on deploying applications instead of managing infrastructure.

    The debate occurring across the IT industry now is to what degree will container-as-a-service (CaaS) environments based on Kubernetes supplant traditional PaaS environments. IBM, as a major supporter of both Kubernetes and Cloud Foundry, is clearly betting there will be room for both. The Cloud Foundry Foundation recently furthered that goal by adding support for a Kubernetes runtime.

    Thus far, however, the complexity of standing up a PaaS environment has limited the adoption of Cloud Foundry to Fortune 1000-class IT organizations or cloud service providers. Meanwhile, CaaS environments based on Kubernetes increasingly are being stood up by developers and then handed over to IT operations to manage. Given that disparity in deployment models, it may not be too long before the number of CaaS environments simply overwhelm the number of instances of traditional PaaS environments.

    — Mike Vizard

  • With a Multicloud Infrastructure, Control is Key

    With a Multicloud Infrastructure, Control is Key

    Ask any developer or DevOps manager about their first experiences with the public cloud and it’s likely they’ll happily share some memories of quickly provisioning some compute instances for a small project or new app. For (seemingly) a few pennies, you could take full advantage of the full suite of public cloud services—as well as the scalability, elasticity, security and pay-as-you-go pricing model. All of this made it easy for teams to get started with the cloud, saving on both the IT budgets and infrastructure setup time. Public cloud providers AWS, Azure, Google Cloud, Rackspace and others made it easy to innovate.

    Fast forward several years and the early promise of the cloud is still relevant: Services have expanded, costs have (in some cases) been reduced and DevOps teams have adapted to the needs of their team by spinning up compute instances whenever they’re needed. But for many companies, the realities of their hybrid-IT infrastructure necessitates support for more than one public cloud provider. To make this work, IT Ops needs a control layer that sits on top of their infrastructure, and can deliver applications to customers over any architecture, including multicloud. This is true, no matter what the reason teams need to support multi-cloud environments.

    Prepare for the Worst

    As any IT Ops manager, or anyone who has lost access to their web app knows, outages and cloud service degradation happen. Modern Ops teams need a plan in place for when they do. Many companies choose to utilize multiple public cloud providers to ensure their application is always available to worldwide customers, even during an outage. The process of manually re-routing traffic to a second public cloud in the event of an outage is cumbersome, to say the least. Adding an app delivery control plan on top of your infrastructure allows companies to seamlessly and automatically deliver applications over multiple clouds, factoring in real-time availability and performance.

    Support Cloud-driven Innovation

    Ops teams often support many different agile development teams, often in multiple countries or from new acquisitions. When this is the case, it’s likely that the various teams are using many architectures on more than one public cloud. Asking some dev teams to switch cloud vendors is not very DevOps-y. A better option is to control app delivery automation with a cloud-agnostic control plane that sits on top of any cloud, data center or CDN architectures. This allows dev teams to work in their preferred cloud environment, without worrying about delivery.

    Avoid Cloud Vendor Lock-in

    Public cloud vendors such as Amazon Web Services or Microsoft Azure aren’t just infrastructure-as-a-service (IaaS) vendors, they sell (or resell) products and services that could very well compete with your company’s offering. In the beginning, using a few cloud instances didn’t seem like such a big deal. But now that you’re in full production and depend on one of these cloud providers for your mission-critical app, this no longer feels like a great strategy. Adding a second public cloud to your infrastructure lessens your dependence on a single cloud vendor who you may be in “coopetition” with.

    Multiple-vendor sourcing is a proven business strategy in many other areas of IT, giving you more options during price and SLA negotiations. The same is true for IaaS. Cloud services change often, as new services are added or removed, and price structures change. Taking control over these changes in public cloud service offerings, pricing models and SLAs is another powerful motivator for Ops teams to move to a multi-cloud architecture. An application delivery automation platform that can ingest and act on cloud service pricing data is essential.

    Apps (and How They’re Delivered) Have Changed

    Monolithic apps are out. Modern, distributed apps that are powered by microservices are in. Similarly, older application delivery controllers (ADCs) were built for a static infrastructure world, before the cloud (and SaaS) were commonly used by businesses. Using an ADC for application delivery requires a significant upfront capital expense, limits your ability to rapidly scale and hinders the flexibility to support dynamic (i.e. cloud) infrastructure. Using ADCs for multiple cloud environments compounds these issues exponentially. A software-defined application delivery control layer eliminates the need for older ADC technology and scales directly with your business and infrastructure.

    Regain Control

    Full support for multicloud in product may sound daunting. After all, Ops teams already have plenty to worry about daily. Adding a second cloud vendor requires a significant ramp-up period to get ready for production-level delivery, and the new protocols, alerts, competencies and other things you need to think about. You can’t be knee-deep in the details of each cloud and still manage infrastructure. Adding in the complexity of application delivery over multiple clouds can be a challenge, but much less so if you use a SaaS-based application delivery platform. With multicloud infrastructure, control is key.

    About the Author / Andrew Marshall

    Andrew Marshall is the Director of Product Marketing for Cedexis, and has driven product marketing efforts at New Relic, Amazon Web Services and Microsoft. Connect with him on LinkedIn.

     

  • LogicMonitor Extends Reach to the Cloud

    LogicMonitor Extends Reach to the Cloud

    LogicMonitor has been making available performance monitoring tools as software-as-a-service (SaaS) applications for several years now. At the Microsoft Ignite conference this week, the company announced it is adding a module through which IT organizations can gain similar insights into public cloud computing services.

    Steve Francis, founder and chief evangelist for LogicMonitor, says LM Cloud is designed to provide real-time visibility into the performance of Amazon Web Services (AWS) and Microsoft Azure clouds, including resource performance monitoring, detailed billing analysis and cloud provider availability.

    Many IT organizations don’t realize just how different managing a public cloud is compared to an on-premises IT infrastructure environment, he says. Not only is too easy to let a workload waste resources, spiraling cloud service costs out of control, but also cloud service providers have policies that limit consumption of resources in a specific region.

    Capabilities provided by LM Cloud include automated discovery of an organization’s entire cloud environment and dashboards that can be employed to troubleshoot issues.

    Francis says that as an extension of the core LogicMonitor service, LM Cloud provides a means for IT organizations to employ one monitoring tool across what have become de facto hybrid cloud computing environments. In fact, using multiple clouds will require IT organizations to rely more on monitoring tools based in the cloud. Otherwise, Francis notes, IT organization would have to correlate data across multiple incompatible tools.

    One of the things that holds IT organizations back from using public clouds is simply that they are more familiar with their on-premises environments. Francis says tools such as LM Cloud will make it much simpler for IT administrators to explore a public cloud environment using a set of capabilities that cloud service providers are not inclined to provide.

    Thanks to the rise of public clouds, DevOps arguably has never been more complicated, with applications distributed across multiple public clouds. But it’s very difficult to manage what can’t be seen, and it’s nearly impossible to compare one public cloud with another—much less an on-premises IT environment—without access to a common baseline of metrics. All too often deciding where to deploy a workload is based on either instinct or corporate fiat rather than detailed analysis.

    While many IT organizations expect to reduce costs by moving workloads to the public cloud, the truth is more nuanced. Long-running applications tend to be less expensive to deploy on-premises. Shorter-run applications lend themselves well to public clouds. Yet, many IT organizations are simply not fast enough when it comes to deploying applications on-premises. Internal IT organizations that have embraced DevOps processes, however, are now more agile. That, coupled with software-defined infrastructure, is narrowing the dexterity gulf that exists between on-premises and cloud computing environments.

    All things may not be equal just yet. But the day when an on-premises IT environment is just another cloud that needs to be managed is that not that far off.

    — Mike Vizard

  • Digital Transformation: Thrive, Not Just Survive

    Digital Transformation: Thrive, Not Just Survive

    My conversations about innovation and the enterprise have afforded me an intimate understanding of the technological challenges companies are facing. Chief among these concerns, regardless of industry or sector, is digital transformation.

    Just the other day, a C-level financial executive came to me seeking guidance on this topic. He said his company was on a mission to become a lean, mean, digital machine, and was currently leading four or five initiatives to modernize operations and convert systems from legacy to new. “We’re moving everything to the cloud, we’re building new apps, and our teams are working toward agile methodologies,” he said, “I’m proud of my teams for all the hard work they’ve put in—in fact, they’re worn out from all their efforts! But honestly, I feel like all this work hasn’t paid off. We’re not seeing the dramatic progress that was promised. What are we doing wrong?”

    He’s not alone in his frustration. I’ve seen many organizations get excited about these kinds of changes, high on the notion that once they’ve knocked out a few initiatives, they will have conquered digital transformation and secured the future of their business through technological fortification. But I reminded him not to get too distracted by all of the technology jibber-jabber, and instead make sure to keep the big picture in mind: Digital transformation is, first and foremost, a fundamental shift in your business model.

    It isn’t simply about switching from outdated technologies to newer, slicker solutions. It’s not about transitioning to the cloud or performing a complete upheaval of legacy systems or processes. And it definitely can’t be accomplished in a few steps or one fell swoop. In reality, digital transformation is a journey that requires a road map and strategic planning to ensure all of your initiatives support the greater movement toward agile, streamlined and more efficient, and directly address and impact your business needs and objectives.

    To this end, I posed a critical scenario to this financial executive: Consider an industry competitor who is smaller, newer, more agile and less bound by the market. If this player were to become super successful, how would your company respond? And which parts of your business specifically would be responsive? His reply was that his company is adopting ideas from new-entry players, primarily online-only banks. He’s building a new mobile platform and revamping his web properties to make banking more efficient for his customers.

    While these efforts certainly have value and no doubt will improve how he does business, it’s not enough to constitute a digital transformation. These changes won’t be enough to drive the fundamental shift that needs to happen. It’s more of a blended approach, which won’t be enough. Hybrid models can allow companies to survive—but not thrive.

    We can draw similarities to the evolution of automotive technology. While internal combustion engine (ICE) cars have long dominated the market, about a decade ago electric vehicles gained real popularity as a superior alternative. However, there have been real obstacles in the way of pure electric vehicles going mainstream. For one thing, we have so much invested in the infrastructure to support ICE cars and very little in the way of making electric cars practical. While charging stations are expanding and becoming more common, we don’t have nearly enough to make pure electric travel the practical choice—for now.

    What has been our interim solution? Hybrid vehicles. In response to the electric contender, we’ve developed a number of vehicles that bridge the divide between infrastructure and efficiency needs. We created ICE-electric hybrids to harness the beauty of electric without having to sacrifice on practicality as the infrastructure works to catch up.

    So this is what our financial executive is actually doing: he’s going the hybrid route by borrowing some of the nice, fancy features from the new entry companies while keeping an entire foot of his company in the traditional ICE world. And though the hybrid movement has been serving us reasonably well with cars, it’s not a good approach when it comes to a technology strategy. In the world of enterprise tech, bi-modal IT is like a hybrid vehicle. Sure, it allows companies to say, “We’re getting more electric!” But if they make the mistake of designating a hybrid operating model as their end goal, they’ll be stuck with split IT personalities and bifurcated cultures.

    Organizations can get by on a hybrid approach, but only for so long. They may be able to modernize in part and reap some of the benefits of better technology, but it just gets too expensive to be sustainable. Hybrid necessitates investing in both types of infrastructure—legacy and new, gas stations and charging stations—to keep services running. In the long run, this holds companies back from truly taking advantage of all the benefits of electric, and they need to build transition technologies between ICE and electric components to make them run as smoothly and efficiently as possible.

    “Okay, so hybrid’s not the way to go. What do I do instead?” the financial executive asked. My answer is to create a space expressly for innovation. You should compile whatever resources you can to create an entirely independent division of your company (or even a separate company) that makes room for innovation. This arm would be free from the constraints of legacy systems, free to ignore the norms of its parent, and free to create its own rules and business model. Using our example from the automotive industry, you can think of it as akin to General Motors creating an entire, standalone electric division, rather than simply converting Chevy models into electric versions.

    While your organization may be in survival mode in the near term, you can’t lose sight of the pure electric play. Think about the inevitability of the electric car age: Battery prices will continue to plummet, driving ranges will increase, charging stations will multiply and the auto industry itself is investing in both EV and air pollution standards. We’re not putting all of our money on oil anymore.

    So as you move forward on your digital transformation journey, be mindful of your true end goal: to have your business thrive through this technology cycle and the next (and hopefully the one after that, too). Going hybrid is a necessarily survival mechanism, but only as long as it builds momentum and helps drive you toward success.

    About the Author / Abbas Haider Ali

    Abbas Haider Ali brings over 16 years of experience in networking, cloud services, software, and cloud communications. As CTO of xMatters, he is responsible for evangelizing the adoption of communications-enabled business processes, and has worked closely with more than 400 global enterprises and IT organizations to create a vision for adopting intelligent communication strategies across business scenarios. Abbas holds a BASc in Computer Engineering from the University of Toronto.

  • VMware Cloud on AWS Will Bring DevOps Issues to a Head

    VMware Cloud on AWS Will Bring DevOps Issues to a Head

    Now that instances of VMware are starting to become available on Amazon Web Services (AWS), a DevOps ecosystem is starting to emerge around the management of applications workloads moving into and out of AWS.

    Among the more than 4,500 applications that VMware claims already support VMware Cloud on AWS are those from Blue Medora, CA Technologies, Chef, Cloudbees, Dynatrace, Jfrog, Puppet, SaltStack and the Ansible arm of Red Hat.

    VMware CEO Pat Gelsinger told attendees at the recent VMworld 2017 conference that VMware and AWS are just now scratching the surface of what they plan to accomplish together. AWS CEO Andy Jassy added that, unlike other alliances, which consisted mainly of marketing, engineers at both companies are working closely together to deliver VMware globally across all AWS availability zones. At present, VMware Cloud on AWS is available in the AWS availability zone hosted in Portland, Oregon. The service soon will be extended to the east coast of the United States, followed by rest of the world over the course of 2018.

    The availability of VMware Cloud on AWS should force several DevOps issues within enterprise IT organizations that have deployed the VMware stack of software mainly on-premises. Many of those organizations have also been employing public clouds such as AWS. But because those environments are based on different hypervisors, it was never easy to migrate workloads between the two platforms. There are plenty of options for running VMware software in the cloud, but because AWS is the largest provider of public cloud services, there are many customers who want to seamlessly move workloads between their on-premises IT environments and AWS via a common stack of VMware software.

    In many organizations the desire to shift applications workloads into AWS will bring many DevOps issues to a head, as VMware and AWS use has occurred in independently of each other. There could be many workloads running on each platform, but for all intents and purposes, IT organizations have managed both platforms in isolation. Now that VMware is becoming available on AWS, all the challenges associated with moving workloads between a public and private cloud come to the fore.

    Most of those DevOps issues will be focused first on moving some classes of workloads running on VMware into AWS. Application workloads that don’t need to run constantly will be among the primary candidates followed by a slew of data protection applications that will enable IT organizations to back up and archive massive amounts of data inexpensively. Next up will be applications that need to be distributed globally to increase availability.

    At the same time, a lot of VMware shops will be moving application development into the cloud. But just because an application is developed in the cloud doesn’t mean it will stay there. Many IT organizations have already discovered that when it comes to long-running applications, the total cost of deploying them on-premises is less than deploying them on a public cloud. The DevOps tasks ahead, of course, will start with figuring out which VMware-based applications make the best candidates from a financial and availability perspective to be deployed on AWS.

    — Mike Vizard

  • IBM: DevOps Challenges Require Managed Services

    IBM: DevOps Challenges Require Managed Services

    The DevOps complexity associated with determining which classes of application workloads are best-suited to run on certain platform types will push an increasing number of IT organizations to embrace managed services. That’s the premise put forth by IBM, which provides such a service.

    Steve Robinson, general manager for IBM Cloud Platform Services, says it’s becoming less likely that internal IT operations teams will have the tools and expertise required to analyze and optimally deploy workloads. In fact, the number of platform choices have already exceeded the ability of most internal IT organizations to master. They include:

    • Traditional virtual machines: The most widely deployed form a virtual machine software comes from VMware. But there’s already a lot of interest starting to emerge in so-called “micro VMs” that promise to reduce the memory footprint of VMs. However, rather than replacing traditional VMs, it’s probable micro VMs would be deployed alongside traditional VMs.
    • Containers: Most containers today are deployed on top of virtual machines because of a lack of tools as well as security concerns. But as IT organizations become more adept at managing containers, many more of those containers will wind up running on bare-metal servers that will be able to attain much higher utilization rates by eliminating the need to deploy traditional virtual machines.
    • Serverless Computing: Based on event-driven architecture, these platforms can be invoked natively as functions or simply be used to host containers. In either case, the need to provision servers, storage and networking resources is eliminated because IT infrastructure resources are made available on demand in real time.
    • Graphical Processing Units (GPUs): As an alternative to Intel Xeon class processors, GPUs now are taking on many workloads involving machine-learning algorithms and big data because of their ability to process many of those workloads in parallel.
    • Field Programmable Gate Arrays (FPGAs): Based on custom integrated circuits, FPGAs are being more widely employed within a variety of cloud services.

    IT organizations today have the option to deploy any of these technologies on-premises or invoke them in the cloud. The issue most are contending with is a lack of advanced IT skills. In the absence of those skills, many IT organizations are in peril of falling behind their rivals. To overcome that issue, Robinson says it’s easier for many organizations to rely on third-party providers to manage their infrastructure while they concentrate their limited resources on application development.

    Any increased reliance on managed services to gain the benefits of a more sophisticated approach to DevOps will vary widely by organization. Crafting DevOps process that span third-party organizations takes time and effort. There’s no way to analyze a workload and then automatically deploy it on the optimal platform without any human intervention. But as IT organizations continue to struggle with mastering DevOps processes, many may conclude it makes the most sense to rely on the expertise of a third-party service provider to manage a hybrid approach to DevOps. Regardless, the pressure to show results by increasing the amount of high-quality code being generated across the enterprise is mounting.

    — Mike Vizard

  • Pivotal Enlists Rackspace to Advance DevOps in Cloud Foundry Environments

    Pivotal Enlists Rackspace to Advance DevOps in Cloud Foundry Environments

    In a sign of the level of complexity now associated with managing DevOps, Pivotal has partnered with Rackspace to create a managed services practice for its distribution of the Cloud Foundry platform-as-a-service (PaaS) environment.

    Ian Andrews, vice president of product for Pivotal, says that at least half of the company’s customers have a least one instance of Pivotal Cloud Foundry (CF) that they would like to have managed by a third party. The reason for that is two-fold. For one, the Cloud Foundry PaaS can be complex for many IT organizations to deploy and manage on their own; Andrews notes that Pivotal releases updates to its distribution of the Cloud Foundry PaaS every 90 days. That’s a cadence the average internal IT organization is not prepared to keep pace with without help from an external services provider, he says.

    Also, increased usage of microservices based on containers running on Cloud Foundry is driving organizations to shift allocation of their own internal resources away from managing underlying infrastructure. By relying on managed services providers such as Rackspace to manage both the PaaS and the underlying infrastructure, Andrews says more resources can be focused on managing the DevOps pipeline.

    Pivotal opted to partner with Rackspace because Rackspace is capable to supporting instances of Cloud Foundry running on a public cloud, in a hosting center or on-premises, he says, adding that 60 percent of the Pivotal instances run on VMware vSphere platform, while the rest are distributed across multiple clouds and other on-premises environments. Pivotal is a sister company of VMware, operating under the umbrella of Dell Technologies.

    Brannon Lacey, vice president and general manager for applications and platforms at Rackspace, says his company is embracing Pivotal as part of a larger push to deliver managed services above the infrastructure level. Previously, Lacey says, Rackspace managed e-commerce and content management applications, then acquired TriCore to add a portfolio of managed ERP application services. However, the company doesn’t have any plans to add more PaaS environments to its portfolio beyond the Cloud Foundry PaaS curated by Pivotal.

    Historically, managed services have accounted for about a quarter of all IT spending. But as the number of deployment options available to IT organizations continue to expand, Lacey says Rackspace is expecting the number of companies that look beyond their internal IT organizations to manage that complexity will only increase.

    As more managed services providers become part of the DevOps pipeline, it’s clear that many companies will soon need to consider how to create processes that extend well beyond their own organizations. That may prove to be a significant challenge because of the cadence of the update process is dictated by the external entities. Of course, IT organizations can dictate the pace of the upgrades. But the further an IT organization falls behind in terms of upgrades, the more expensive the managed service tends to become. In short, there’s no such thing as a proverbial DevOps easy button.

    — Mike Vizard

  • Barracuda Networks Enhances API to Advance DevSecOps

    Barracuda Networks Enhances API to Advance DevSecOps

    Recognizing that DevOps teams deploying applications in the cloud need a more sophisticated approach to security, Barracuda Networks at the Microsoft Inspire 2017 conference unveiled an enhanced REST API for its Web Application Firewall (WAF), in addition to providing integration with the IT automation framework developed by Puppet Labs.

    At the same time, Barracuda Networks revealed that it has integrated all of it firewall offerings with the Microsoft Operations Management Services running on the Microsoft Azure Cloud. Finally, Barracuda Networks announced it is now including a software-defined wide area network (SD-WAN) capability with the Barracuda NextGen Firewall platform.

    Tim Jefferson, vice president of cloud for Barracuda Networks, says the REST API the company is exposing in its WAF enables IT organizations to better manage security within the context of larger DevOps environment. As part of that effort, Jefferson says, Barracuda Networks also plans to integrate its WAF offering with other IT automation frameworks.

    Jefferson says many IT organizations are discovering that public clouds are more secure than on-premises environments because of the level of security and instrumentation that cloud service providers now routinely include. For example, cloud service providers make it easier to track unusual API calls that might indicate an IT security breach or even an attack in progress. Those capabilities, says Jefferson, make it easier for vendors such as Barracuda Networks to provide more visibility into what’s occurring in a public cloud than what’s generally feasible on-premises.

    However, each cloud service provider has its own unique network stack that requires security tools to be optimized for each platform, says Jefferson. Because of that issue, most IT organizations have not had the security wherewithal needed to rise beyond adopting more than one public cloud service in their production environments, he says.

    In general, Jefferson says, developers are not likely to consume security technologies on a public cloud that can’t be invoked via an API. Because of that issue, many IT organizations are discovering that the security platforms they have employed on-premises simply can’t be lifted into the cloud. That issue, he says, creates a level of friction inside the organization that inevitably hampers usage of cloud platforms more than any other challenge an IT organization faces. Cloud applications require a DevSecOps approach that developers will view as a natural extension of existing DevOps processes, says Jefferson.

    To achieve that goal, organizations need to make it easier for developers to secure their applications and invite IT security experts inside their organization to participate in, for example, scrum teams that collaboration build, deploy and manage applications. In fact, Jefferson notes most DevOps teams don’t even want to talk to a vendor’s sales representative; they prefer to be able to download code that they can test and deploy on their own before committing to buying a license.

    It’s still relatively early in terms of appreciating the impact DevSecOps will have on improving IT security. But one thing is clear: IT security vendors that don’t make it simple for developers to invoke the capabilities they provide soon will be left behind.

    — Mike Vizard

  • Data Science Industry Perspectives in the Cloud

    Data Science Industry Perspectives in the Cloud

    In principle, the cloud is becoming a commodity. Google, Amazon and other companies are trying to commoditize almost everything, including the instruments for data gathering, data storage and data transformation. In the near term, we should expect that platform engineering, which today is overly complex, will become simpler.

    With data engineering, however, the prospects of such simplification in the near future is not that clear. Currently there is no single simple solution even for ETL (extract transform load), such as the Amazon Data Pipelines or Amazon Glue (which hasn’t been fully released). They represent some very humble beginnings of what people are building up right now brick by brick. Data engineers and architects and other professionals are building these to solve real-life cases.

    From the data science point of view, new machine learning-as-a-service solutions are popping up like mushrooms after a spring rain. There are a multitude of them on the market: Big ML, Data Robot, Azure ML, Amazon ML, IBM Watson, Google Prediction and so on. But what is machine learning as a service (MLaaS)?

    Let’s look at IBM Watson Analytics as an example:

    MLaaS is a set of preset wizards to create machine learning models and use these models through API. For example, we need to recognize text and separate some facts and data out of it. To do that, we initiate the service in a couple of clicks, insert the original text and get back a marked out and analyzed copy. In this instance, the service is commoditizing NLP (natural language processing). The same goes for VTT (voice-to-text): We insert an audio file and get the text version of the talk back.

    There are other uses of machine learning technology:

    Machine learning closely works with data. But it is one thing to have data, and another to have actionable data with which you can help users. As seen from the chart, above one of the key trends is the commoditization of data services.

    These basic services do what they are supposed to, and this is great. And you don’t need to employ a data scientist to do some of these tasks. But if you are a company like Grammarly, whose know-how is in actual text recognition, provision of recommendations and text analytics, then ready-made services are insufficient. Grammarly, and companies like it, have to take a hands-on approach that will be very expensive. This is their core business and using third-party services is not viable.

    So how would you go about using ML cloud services?

    Even taking into account a large number of “as a service” solutions, the main challenge is in navigating and understanding “what is better” and “what is best,” and “how it all works.” The issue is that such services are constantly changing. The best choice for you may be to employ tools-consulting services. It’s imperative to understand what is available now and what tools would best suit your business. This is the most basic but essential help you may need.

    Secondly, integrating your operations with these services requires particular engineering efforts. Indeed, most of the data science tasks right now are solved through these cloud “as a service” solutions. But having a proper consulting company with a strong engineering background can help you better utilize such ready-to-use solutions. They offer value to the business at a faster pace. There is no need to invent the wheel, especially when your consultant knows what and where to use.

    If you decide to go to a data science firm where the majority of employees are data scientists, they will create for you some unique genius custom solutions, do great research and so on and so forth. This is what they are good at. This is their bread and butter.

    An end-to-end consulting company may be a better choice for your company, as its goal is to bring value to your business. Consultants will tell you if MLaaS solutions are appropriate for your machine learning needs, and will have a deep understanding of how these services work. A consultancy company also should create and build proper architecture, and provide custom development work that is unique to your services for your business to scale.

    Finally, evolution is key if you plan to grow your business. Start with the ready-made solutions, then in time switch to in-house solutions that can be done with the help of a group of data scientists.

    About the Author / Stanislav Ivashchenko

    Stanislav Ivashchenko is the Senior DevOps Сonsultant at SQUADEX. A certified AWS solutions architect, he is experienced in building, delivering, supporting and optimizing a broad range of software applications. From bare metal to the cloud, from monolith architecture to microservices, he helps improve software delivery processes in startups, mid-sized companies and large enterprises. He has solid skills in orchestrating various DevOps and infrastructure related tools, services and management practices. Connect with him on LinkedIn.