devopsy.kinsta.cloud

Category: DevOps in the Cloud

  • Trend Micro Expands DevSecOps Portfolio

    Trend Micro Expands DevSecOps Portfolio

    At the AWS re:Invent 2017 conference today, Trend Micro significantly expanded its reach into DevSecOps by announcing it has acquired Immunio, a provider of agent software that can be employed on a central platform engine to execute security policies on a granular level.

    In addition, Trend Micro announced it is adding support for container image scanning to its portfolio of security products as well by the spring of 2018.

    Mark Nunnikhoven, vice president of cloud research for Trend Micro, says both the Immunio policy engine and the container image scanning technology are now part of the Trend Micro Hybrid Cloud Security family of offerings that the company plans to expand for developers. Those capabilities, in turn, are exposed to developers deploying applications on-premises or in a public cloud primarily through its Trend Micro Deep Security cloud service, a suite of security technologies and threat detection services exposed by application programming interfaces (APIs).

    Nunnikhoven notes Trend Micro has seen a significant increase over the last several years in the use of programmatic approaches to managing security. Most of the shift has been driven by developers who have driven security to the left as part of the rise of DevSecOps. But he says security professionals are also starting to develop programming skills to advance IT security both in the cloud and on-premises.

    Nunnikhoven says the rise of containers is making DevSecOps more challenging. Too many developers are still grabbing containers from registries without checking them for vulnerabilities. As many as one-third of containers may contain known vulnerabilities, he says. To address that issue, Gartner estimates that by 2019 more than 70 percent of enterprise DevSecOps initiatives will have incorporated automated security vulnerability and configuration scanning for open-source components and commercial packages. That compares to less than 10 percent in 2016.

    IT organizations, however, don’t just want to be able to scan container images. Nunnikhoven says it’s clear they want a set of integrated security tools that can be employed to secure both the containers and the hosts they are deployed on. In the case of Immunio, Trend Micro is adding a security technology that can be embedded in applications running on virtual machines or bare-metal servers, as well as containers making up a microservice.

    While Trend Micro has a long history of providing security products to IT and cybersecurity professionals, it and virtually every other security vendor are competing against a host of startups that have embraced DevSecOps to change how security technologies are consumed. In its effort to remain relevant, Trend Micro is expanding its portfolio of products to focus more on developers. Over time, however, Nunnikhoven expects there will be increased collaboration between developers and IT security professionals, as the lines of responsibility for various aspects of security are better drawn.

    In the meantime, however, Trend Micro—like most of the vendors in the IT security industry—is now clearly making a hard shift to the DevOps left.

    — Mike Vizard

  • Micro Focus Unfurls Functional Testing Service

    Micro Focus Unfurls Functional Testing Service

    The merging of software assets from Micro Focus and Hewlett-Packard Enterprise (HPE) that occurred earlier this year included StormRunner, a series of load- and performance-testing tools. Micro Focus recently extended that portfolio with the introduction of Micro Focus StormRunner Functional, a suite of functional testing tools delivered as service that can be employed to test applications running on any browser, operating system or mobile device.

    Shane Evans, director of product management for application delivery management for Micro Focus, says StormRunner Functional spans a variety of automated tests addressing unified functional testing (UFT), UFT Pro and Selenium browser testing tools that include elements developed by both HPE and Micro Focus. The Micro Focus StormRunner Functional Testing service also includes pre-built integration with Google Analytics, Micro Focus Octane, GIT and Jenkins to streamline the testing process.

    Interest in automated testing has increased substantially in the last few years, says Evans, because developers are under more pressure than ever to roll out new applications and associated updates faster. Unfortunately, most developers don’t have the time required to test applications themselves, or there is simply not enough money in the budget to hire quality assurance teams to test every element of an application. Micro Focus StromRunnner Functional provides an alternative approach using a set of testing tools that have been widely employed across the enterprise for decades, says Evans.

    Evans notes Micro Focus is pursuing a comprehensive approach to application delivery management spanning everything from testing tools to application lifecycle management. Micro Focus is making the contention that most DevOps teams are a lot more interested in getting access to the results of a test than managing the actual testing technologies themselves, says Evans. In addition, advanced analytics and machine learning algorithms, which now are standard elements of testing process, require access to massive amounts of data to be effective. That data is a lot easier to aggregate in the cloud using SaaS applications than in an on-premises environment. In fact, Evans says, those requirements are among the factors driving a wave of recent acquisition across the application testing sector.

    Arguably, the biggest testing challenge organizations now face is moving away from processes based on IT Information Library (ITIL) guidelines to a more DevOps-centric process, under which continuous testing is more embedded within the application development process, Evans says. Functional testing is only one element of the testing process, but it has become more critical as end users become less forgiving of substandard digital experiences inside and out of enterprise IT environments. Regardless of who inside the organization is responsible for testing applications, the expectation now is that every application experience inside the enterprise will be on par with a consumer application experience.

    — 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

  • 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

  • The Cloud and DevOps: Like Peanut Butter and Jelly

    The Cloud and DevOps: Like Peanut Butter and Jelly

    Cloud is practically designed for DevOps. No matter which cloud provider you are using, each has set up systems designed to spin up/spin down on demand, has the ability to run pretty much what you need and offer APIs/command lines to achieve your DevOps goals on the infrastructure side.

    That means that the infrastructure side of DevOps can be handled by careful choice of base image, some scripts to configure network and other supporting infrastructure, and some scripts to install what’s needed once the instance is running and protected.

    Not All Roses …

    The problem is one of breadth and complexity. Yes, cloud is the perfect place to spin up DevOps, at least on the infrastructure side and, once you have a Jenkins instance, on the coding side, too. But the complexity masked by “spin up the infrastructure side” can be daunting. Different sets of APIs for servers, storage and networking, and sometimes different APIs for security versus accounts … It can get snarled quickly.

    So, What to Do?

    What can you do to make life in cloud automation/DevOps easier? There are numerous options available to you to simplify the operational part of cloud DevOps and allow you to focus on discussing issues and resolving them.

    First on the list is the growing amount of automation of cloud automation. Sound crazy? It’s not—just my way of expressing that cloud vendors provide you with APIs and tools such as Puppet are getting better at wrapping those APIs for you, so you can focus on problems, not what is supposed to be the solution.

    This idea is extended by companies that are tying disparate APIs together into a unified whole in one segment or another. One example of this is CloudCoreo, whose tools can do security audits of cloud deployments. The company takes the time to wrap the various security-related APIs and let you pick what is important for your team to monitor.

    There also is an entire market segment growing up of both consultants and VARs that will help an enterprise move to the cloud. Most of these companies focus on one vendor or another, but all share a desire to help make the shift to the cloud easier. By way of examples to get you started, consider Neoxia (in the EU) for GCE, Accenture (in North America) for AWS or Atmosera (in North America) for Azure. (Note: I have never used the cloud services of any of these companies; I’m merely offering you a sampling of what is available. Check your cloud providers’ partners page for more partners.)

    Another option that will reduce, but not eliminate, cloud-based complexity is to use containers to set up the application. The container can then be run on whatever cloud platform suits your needs (or in your data center, if that’s the preference). Any instances spun up still must be protected and given access, but most of the networking, security and instance complexity can be handled at the container management level.

    In fact, if you implement container management and choose for interoperability, a container management tool such as DC/OS can let you choose at deployment time where to put the container.

    Seeing what enterprises are starting to do with containers and entire build/test environments, it is possible that very soon you will be able to just kick off a job, have it build containers that will run your DevOps processes, run tests, deploy to other containers and then go away once the relevant data from them has been saved. The containers used along the way, by taking advantage of a multitarget container management platform, could be anywhere.

    To Sum It Up: Cloud is Good for DevOps

    The issue at hand—as it has been for DevOps and cloud for a while—is the rate of change. Here we’ve discussed a cross-section of ways to make DevOps in the cloud easier and more complete. But no doubt we’ve missed some great ideas and products, because there is so much going on.

    The point is, tools are coming available to make it easier. Don’t write a billion miles of scripts that are useful for only one provider if you can avoid it. Look into these options (and others that will crop up) to lighten your load of technical debt moving forward, and make getting DevOps roaring in the cloud easier.

    And as always, keep rocking it. The change has been constant, and you’re still cranking. That says a ton.

    — Don Macvittie

  • Kubernetes is the Universal Cloud Infrastructure

    Kubernetes is the Universal Cloud Infrastructure

    Before I started Rancher Labs, I created a company called Cloud.com where we developed Apache CloudStack. We were inspired by the early success of Amazon Web Services (AWS) and wanted to make it possible for everyone to stand up AWS-like cloud infrastructure for themselves.

    While CloudStack was successful in powering a number of public and private clouds, it failed to achieve mass adoption. Instead, cloud infrastructure today is increasingly concentrated in a small number of very large public cloud providers such as AWS and Microsoft Azure. There are a few reasons for this:

    1. It takes a lot of capital investment and operational expertise to operate cloud infrastructure. Only large players can benefit from economy of scale.
    2. There is no consistency among different cloud infrastructure providers. Even if a smaller provider can beat an established player on price, it becomes increasingly difficult for customers to migrate workloads from one cloud to another.
    3. The scope of cloud infrastructure services is forever expanding. It is no longer sufficient to offer basic compute, storage and networking services. Leading providers such as AWS offer an ever-growing number of services for data processing, analytics and artificial intelligence.

    Despite the downside of cloud lock-in, organizations are facing increasingly fewer choices in cloud infrastructure as they adopt cloud computing.

    Enter Containers and Kubernetes

    We started Rancher Labs because we saw that containers can potentially change the game in cloud computing. Docker is a universal application packaging standard that makes applications portable. Kubernetes adds cluster management to Docker. Many people think the power of Kubernetes lies in its ability to manage applications and microservices. We completely agree. We believe, however, that Kubernetes also brings significant benefit by hiding the differences between cloud infrastructure providers. Kubernetes comes with a rich ecosystem of plugins for storage, networking and load balancing. As a result, it does not matter where you have deployed Kubernetes. As long as the drivers are configured correctly, users get a consistent view of cloud infrastructure regardless what cloud provider they use.

    In addition to offering consistent storage, networking and load balancing, Kubernetes also brings with it a rich ecosystem of higher-level services for developers. The Cloud Native Computing Ecosystem includes all major providers of system- and platform-level software. Kubernetes has become the center of gravity of innovation in cloud computing. New capabilities are made available at a faster pace than anywhere else.

    In the early days, it was quite challenging to setup and run Kubernetes. Companies such as Rancher created Kubernetes distributions that make it easy for DevOps and IT teams to deploy and operate Kubernetes clusters. Today, many cloud providers offer Kubernetes as a service. At Rancher, we are now more focused on managing Kubernetes clusters. We expect most, if not all, major cloud providers to support Kubernetes in the future. When that happens, Kubernetes will be the universal cloud infrastructure.

    If you use cloud computing, there is no reason not to use Kubernetes. You get the most complete ecosystem support and the same consistent experience no matter where you go. Cloud lock-in will be a thing of the past.

    About the Author / Sheng Liang

    Sheng is a co-founder and CEO of Rancher Labs. Prior to starting Rancher, Sheng was CTO of the Cloud Platforms group at Citrix Systems after their acquisition of Cloud.com, where he was co-founder and CEO. Sheng has more than 15 years of experience building innovative technology. He was a co-founder at Teros, which was acquired by Citrix in 2005 and led large engineering teams at SEVEN Networks, and Openwave Systems. Sheng started his career as a Staff Engineer in Java Software at Sun Microsystems, where he designed the Java Native Interface (JNI) and led the Java Virtual Machine (JVM) development for the Java 2 platform. Sheng has a B.S. from the University of Science and Technology of China and a Ph.D. from Yale University. Follow him on Twitter.

  • Building a Services and IoT Platform with DevOps, Part 4

    Building a Services and IoT Platform with DevOps, Part 4

    IoT platforms and their solution development have crossed different maturity levels. At first, devices were primitive, isolated and working with limited functions before slowly evolving to communicate and connect with other devices using lightweight communication protocols, and then stepping into advanced level with remote management of devices, harvesting the data from devices and smart decisioning and analytics. Beyond that, IoT has moved to optimized levels of using multiple technology options and adopting cloud and DevOps disciplines to build intelligent IoT solutions.

    This article focuses on giving insights on choice for IoT platforms and factors influencing build or buy options for IoT solutions, different hosting options, factors on IoT development in the cloud and more.

    IoT Platforms: Build, Buy or Both?

    The dilemma of whether to build an IoT system from scratch or buy an off-the-shelf platform still continues. Below are some of the key factors to consider before making the critical decision.

    1. Price: If you plan to build an IoT platform, the infrastructure setup and operation costs can be high. And, as you plan to scale, there will be additional infrastructure cost in setting up additional data centers in that region. If you buy an IoT platform, prebuilt infrastructure is available across global data centers to scale out on a per-usage basis. Plus, you get the the benefit of buying devices from a certified partner ecosystem with discounted device prices. You can buy a few devices from cloud vendors or other device manufacturers, and use mix of devices, mix of cloud/multi-clouds or on-premises, using mix of platform as a service (PaaS)/infrastructure as a service (IaaS) at competitive prices.
    2. Time to Market: A house-built IoT systems will typically take about six to 12 months to complete, including infrastructure setup, device development and software development and testing. Depending on the complexity of the business case, the release cycle may take even more time to get to production, especially with ongoing device technology updates, lack of protocol standards and new business demands.
      Under the buy option, you can buy preconfigured end-to-end solutions available for common IoT use cases such as remote monitoring, predictive maintenance and connected factory, and these solutions can be customized based on need. You can even try to build only few components of IoT solution which may not be available from the vendor, such as the devices/edge, build a field gateway and use preconfigured solutions for data ingestion and data processing, data analytics and data storage components. There are starter kits available to quickly prototype, evaluate and deploy, eliminating spending more cost and effort, before hitting to the ground.
    3. Skillset/Expertise: Building an IoT platform requires a skilled team with expert knowledge of software and hardware and development, which costs more. Currently there is lack of skilled IoT experts with a mix of software and hardware knowledge in traditional industrial-based enterprises.
      When buying a IoT solution from vendors, the solutions are prebuilt and guided by standards and best practices. The platforms are built by experts who are proven with cloud infrastructure, based on their experience working with large customer base and customer support—necessary for IoT platform development.
    4. Scalability: When you plan to scale your business, you need to scale your infrastructure as well. With millions of devices connecting to your infrastructure to send and receive data and firmware updates, monitor the devices, support multiple range of network providers and store large volumes of data being collected and processed, you need a scalable infrastructure on-premises or in the cloud to meet those demands. Setting up a scalable infrastructure on your own requires skilled labor, effort and cost.
      Real-time streaming and data processing capability is available for large volumes of data workload, enabling scaling of individual components of IoT solution, as well scaling as scale units (group of components for data ingestion, data processing and data storage). Choices of different cloud vendors give you options to scale based on demand, horizontally or vertically, adding/removing devices with portability options and providing on-demand simulated test environments with the flexibility to choose multiple clouds or a mix of PaaS/IaaS options from different clouds or hybrid infrastructure.
    5. Security: For in-house IoT development, teams should be aware of various security attacks and develop systems with current security strategies and technologies to both protect data and devices and maintain data privacy. A large infrastructure is needed to support the sandboxed hosting of data in separate geographic regions for secure data storage, device security and user security.
      IoT platform vendors provide security standards. For example, Microsoft provides SDL (Security Development Lifecycle), which enables developers to follow the standards during device development and ensures development happens with security built at all parts of system. These platform providers have prebuilt infrastructure for secure data storage, cloud security, user security, application security and device security, and has separate security teams to protect the data at all levels.
    6. Analysis & Visualization: It’s estimated that 90 percent of the large volumes of data collected from millions of devices remains unused in most enterprises. To tap the data for valuable business metrics, data analysis/algorithms should be updated as industry and device requirements change and extensions are needed to integrate data with data analysis tools to churn the data. There are open-source and proprietary tools available for data mining and data analytics and custom dashboards must be built to monitor the telemetry, setup rules and actions.
      Preconfigured solutions and most IoT platform providers have out-of-box data analysis tools integrated and rules can be defined to analyze data with customizable dashboards, enabling you to focus more on business outcomes and how to churn/mine data, rather than focusing on building algorithms/tools/dashboards from the scratch.

    Factors Driving Cloud-based IoT Development

    Considering the various factors, a hybrid option with mix of buy and build for IoT platform components is better compared to building the platform from scratch, as you get out-of-the-box features from the off-the-shelf platforms that are customizable and extensible to business needs.

    The following are some of the factors driving more and more IoT development in cloud (single/multi-cloud/hybrid), making IoT grow exponentially:

    1. Increasing number of devices – billions/trillions of devices interconnected
    2. Need for remote processing power and high compute
    3. Need for hyperscale systems for processing hot/cold/warm/fast data pipeline with low latency
    4. Need a platform that can quickly evaluate, prototype and deploy IoT applications
    5. Need a platform that provides security by design across devices, gateways, networks, data processing, users and applications
    6. Usage of advanced analytics and monitoring solutions available in cloud
    7. Leverage interdevice communications, interservice communications
    8. Utilize preconfigured IoT solutions for most of the popular use cases such as remote monitoring, predictive maintenance, with proven practices/patterns.
    9. High data storage, highly scalable with minimum cost to deploy
    10. QoS features in cloud—security, performance, usability, backup, etc.
    11. Cloud gateway providers have support for various devices and provides extensibility
    12. Cost of devices, cost to deploy and internet usage has dropped
    13. Out-of-box support and availability of big data and machine learning techniques in the cloud with mobile data visualization
    14. Ease of integration with DevOps tools in cloud, end-to-end testing with simulated devices as containerized environments in cloud

    Expanded internet connectivity, reduced cost of devices, increased spread adoption of remote devices such as smartphones, usage of big data, machine learning techniques and cloud adoption, competitive pricing models and more are the key drivers for IoT’s growth in cloud.

    About the Author / Lavanya Subbarayalu

    Lavanya Subbarayalu is Senior Architect working with Technology Office in HCL Technologies. She has expertise in IOT, Azure, DevOps consulting & Microsoft technologies. She is associated with DevOps COE, working on design and Development of DevOps solutions and consulting tools. Connect with her on LinkedIn.

  • Case Study: DevOps Key to AWS Cloud Migration

    Case Study: DevOps Key to AWS Cloud Migration

    DevOps practices halved the time it took this SaaS company to migrate to AWS

    Australia-based Whispir provides communications applications as a service. One of its goals is to get products into users’ hands as soon as possible, and that requires development, operations and product staff working together, said Jonathan Swift, head of product and operations.

    Whispir formerly operated from a co-location data center, a model that continued as it expanded internationally. But the time and effort needed to run the systems was not cost-effective for an organization of its size, so the company switched largely to AWS. Governance issues faced by some clients force the company to still run its own systems in certain geographical locations.

    In the process, “[We] learned a lot about our app and how to make it cloud-ready,” said Swift. “Cloud isn’t free, cloud isn’t cheap” and is potentially more expensive than placing servers in co-lo data centers if the software isn’t built correctly.

    For example, it makes sense to make the most use of a physical server as it is largely a fixed cost. But in the cloud, the fewer resources you use, the less it costs.

    Crises Lead to Spikes

    On the other hand, a lot of Whispir’s business is crisis-focused (eg, Caltex uses Whispir at its Kurnell oil refinery in Sydney to send emergency messages), and it takes a certain amount of time to spin up additional instances to deal with spikes in message volumes. “That was a real challenge,” said Swift.

    Those crisis-communications clients expect Whispir to have sufficient resources to meet sudden demand. That’s an expensive proposition with co-located hardware, whereas Ccloud resources can be scaled up quickly, though not instantaneously.

    Seasonality has to be taken into account. One relatively predictable driver of crisis messaging is Australia’s bushfire season. Unfortunately, this overlaps Christmas, which is a peak time for marketing messages. So Whispir plans to run at around 200 percent of its normal baseline capacity during the fire season. This is easily done with cloud infrastructure, which Swift describes as “a beautiful thing” in this context.

    Some organizations are scared by multi-tenant environments. The ability to stand up dedicated instances on AWS is a great feature that Whispir can offer, especially to its clients in the financial sector.

    The company’s DevOps practices had been focused on the co-location environment, so even though kanban still “works very well for us” after moving to AWS, some previous choices had to be revisited. In particular, new monitoring tools were needed to cope with the elasticity inherent in the cloud and because the focus expanded from the hardware to the whole stack.

    Selected tools included the Zabbix open-source monitoring platform and Sumo Logic for trend analysis.

    Earlier this year, Whispir moved all of its Australian customers into a “pure AWS” environment. There are some great tools for migration, Swift said, “but it’s not as straightforward or seamless as you might think.” He recommends doubling any initial estimate of the time required for such projects.

    There were some nasty surprises: The first month’s bill from AWS was “huge” and it took a couple of months to determine the cause, even with the aid of AWS’s “really beneficial” premium support service.

    Security requirements in various jurisdictions had to be taken into consideration, with updates to various procedures to ensure the new cloud environment was compliant. For instance, the procedures required when a physical system was decommissioned were well-understood, but how could they be translated into a cloud environment? One specific example is that an in-house storage device can be destroyed when it reaches the end of its life, but in the cloud it’s largely a matter of relying on the provider’s controls.

    Avoid Lock-In

    But Swift warned that “the challenge is to not lock yourself in” to a particular cloud provider. For Whispir, which operates a mixed cloud/on-premises environment (no cloud provider offers the right onshore facilities in New Zealand and the hardware that Whispir has installed in Singapore is too new to be replaced by IaaS), that is a requirement rather than a strategic choice.

    Whispir would have avoided AWS-specific features that would make the platform easier to use and more difficult to get out of, despite the fact that using provider-specific toolsets can yield significant cost savings.

    Whispir is keeping an eye on Azure—”great tools, great partnerships, great ecosystems,” observed Swift—and may migrate to Microsoft’s cloud in around 18 months.

    A particular advantage is that Azure Stack can be run on private hardware, which could be useful if Whispir decided to enter a market where Microsoft Azure wasn’t present.

    Either way, the intention is to go 100 percent cloud to the extent that is possible.

    ‘Infrastructure as Code’ Means More Power for Ops

    The move to the cloud has made Whispir’s operations people more powerful, he observed. The infrastructure-as-code concept allows for rapid deployment, enables operations to contribute more to product development, reduces risk and enables the company to be more responsive to the market.

    Furthermore, dealing with on-premises hardware still very much a waterfall situation, thanks to the delays and dependencies involved. But moving to IaaS means infrastructure issues sit comfortably within the kanban model.

    IaaS also means that various network-related tasks simply disappear, but other issues arise in their place. For example, some external services used by Whispir (eg, SMS gateways) require the use of VPN connections from a known IP address, but with cloud infrastructure the best you may be able to do is specify a range of addresses. Whispir’s short-term fix was to route such connections through a specific server in the co-lo center, and in the longer term it found providers with less-restrictive arrangements.

    Moving from co-lo to cloud would have been “incredibly hard” without DevOps, Swift said. It would have taken at least twice as long, he noted, and the company wouldn’t be able to run the mixed environment as well as it does.

    “There’s no way we would have been so successful” without DevOps, he said.

    — Stephen Withers

  • DOES17 Speakers Share Insights on Live Podcast

    DOES17 Speakers Share Insights on Live Podcast

    As DevOps Enterprise Summit San Francisco (DOES17), slated for Nov. 13-15, inches closer, event founding partner Electric Cloud hosted a special episode of Continuous Discussions (#c9d9), featuring some of the conference speakers. During the discussion, the speakers shared some of their recent DevOps transformation stories and a bit about what to expect during their talks at the conference.

    The panel included:

    • John Esser, senior director of IT and data center operations at AdvancedMD;
    • Gary McKay, scrum master at Somos;
    • Aloisio Rocha, agile product owner at NetEnt;
    • Manish Aggarwal, software engineering manager at Intel;
    • Marc Priolo, global software configuration manager at Urban Science;
    • J. Paul Reed, managing partner at Release Engineering Approaches;
    • Marc Hornbeek, principal consultant – DevOps at Trace3;
    • Gary Gruver, founder and CEO of Gary Gruver Consulting; and
    • our very own Sam Fell and Anders Wallgren.

    Here is a list of the most memorable takeaways from the discussion:

    Every company is different, so approaching a DevOps transformation will vary based on the organization, explains Esser. “Every company has a different set of constraints, a different culture, different things they value. So you can’t just say, ‘Oh, I’ve got this DevOps hammer, and I’m going to start pounding away.’ We understand the principles, but how to apply those and how to execute those principles are quite different.”

    McKay on the success of moving from mainframe to microservices with his “Team Dragon” concept: “Team Dragon was formulated to make sure that our CI/CD process as well as our deployment and release processes were consistent. Coming from a mainframe environment to, say, a distributed microservices environment, there are differences not only in culture, but processes and technology. We wanted to make sure all that was managed efficiently and effectively, so that we could do deployments when we needed to do deployments.”

    Rocha on the NetEnt DevOps journey and what inspired the transformation: “We’ve gone from a place where the business was expanding, but deployments and deliveries were not scaling with the business to working on how to tackle it with automation, working with the deployments and making the deployments visible to everyone.”

    Aggarwal will be talking about the DevOps journey at Intel at DOES17: “I will be covering as to how a lot of organizations, including Intel, are trying to board the journey of DevOps. They are successful to an extent, but how to make sure that the quality, which is the sole purpose of this journey, does not get left behind.”

    Priolo on his pipeline-as-a-service strategy: “We have a pipeline-as-a-service strategy. That’s where we want to make sure that our developers can concentrate on developing instead of trying to figure out how their code is getting into our production environment.”

    Gruver’s simple advice on starting your DevOps transformation: “In the beginning, you need to create some positive momentum. You need to find the things that are the most broken in the development and deployment operations. You need to highlight them. You need to get them fixed. Then you need to market those changes, so that you get some positive momentum for the transformation.”

    Don’t forget about the human factor of release engineering, says Reed: “[At DOES17] we’re going to be going through a little bit of the human factors that are related to release engineering. There’s a couple of facets of that. It’s sort of, ‘How do you go about doing the work,’ and then also a bit about how we treat others, the net system.”

    It’s important to include all teams on your transformation journey, per McKay: “The secret is inclusiveness. Making sure that the mainframe team is part of the microservices process and making sure that we, in our haste to get things done very quickly and very effectively, make sure that we bring them in. We make sure that their roles are purposeful and that they’re part of the process and not just, ‘Oh, you’re just some mainframe guys. We’re just going to ignore you.’”

    Esser on the core values of DevOps: “DevOps as a whole is not limited just to an architecture. DevOps, at its core, is about working better together and increasing the flow of value across the whole value pipeline.”

    It’s important to find the right balance between allowing your developers to be unique, but also adhering to the rules, says Priolo: “The real challenge is trying to find out a way to allow developers to still have their snowflake ability, while still complying with the standards of the company. It’s not to make everything stringent and follow the same exact path. It’s to create a pipeline that gives them the flexibility, but still gives us the ability to do auditing, to make sure that the code is being checked at its proper place.”

    Sometimes it takes a big mistake or bug to make you realize you need DevOps, explains Rocha: “Our process was intense before, to say the least, especially when some scary bug came or a heavy compliance requirement came in that we had to fulfill in a short amount of time. That made us realize we have to fix this.”

    Wow – Aggarwal’s team at Intel went from almost complete manual testing to 100 percent automation in seven years: “When we started about seven years ago, 99 percent of our testing was manual, and everything was repetitive. The work was getting more challenging, and the sheer amount of it was growing with every release. So it was very important to bring that under control. The only way of doing that was end-to-end automation. When I say, ‘end-to-end,’ it’s not 99 percent. It’s 100 percent totally touchless automation.”


    Reed on the human factor of versioning: “Versioning really is about humans communicating with each other. They’re trying to encode information into that version number, which is, I think, one of the reasons you see people bikeshedding that a lot.”
    DevOps can expose your longstanding problems, says Gruver: “When you start trying to increase the frequency of build/test cycles or deploy cycles, you see inefficiencies repeating. You see the trends. There’s a bunch of tools in the DevOps toolbox that enable you to go after that.”


    Moving from monolith to microservices is not an overnight transition, explains Wallgren: “Time and time again we hear the difficulties that everybody has with legacy applications or monolithic applications. The transition away from mainframes is not an overnight kind of thing. They’re not going anywhere, anytime soon.”

    There’s still value in mainframes, and getting that to customers is key, explains Fell: “There’s a ton of value locked up in mainframes and being able to get that out to other people in a service-oriented sort of way. It’s a hard migration to do, but that cultural aspect of making teams feel like they’re comfortable working with one another is critical to getting through that part of the process.”

    Watch the full episode:

    About the Author / Anders Wallgren

    Anders Wallgren is chief technology officer at Electric Cloud. Anders has over 25 years’ experience designing and building commercial software. Prior to joining Electric Cloud, he held executive positions at Aceva, Archistra, and Impresse and management positions at Macromedia (MACR), Common Ground Software, and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7. Anders holds a B.SC from MIT.

  • DevOps Chat: Cloud Sprawl, DevOps and ParkMyCloud w/ Jay Chapel

    DevOps Chat: Cloud Sprawl, DevOps and ParkMyCloud w/ Jay Chapel

    I bet you know how many instances you have running AWS or Azure or Google Cloud. OK, maybe you don’t. But whether you do or don’t, do you really have a handle on what your cloud infrastructure looks like? If you are like most, the answer to the question is no. Cloud sprawl, multicloud, hybrid cloud … it is hard to get a handle on this. In this DevOps Chat we sit down with Jay Chapel, CEO of ParkMyCloud and discuss how really understanding your cloud infrastructure can help DevOps deliver better.

    As usual, the streaming media of our conversation is below, followed by the transcript of the conversation:

    Audio

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, and it’s time for another DevOps Chat. Today’s DevOps Chat guest is Jay Chapel, CEO and Co-founder of ParkMyCloud. Hey, Jay, welcome to DevOps Chat.

    Jay Chapel: Hey, Alan, how’s it going? Thanks for having us.

    Shimel: Oh, thanks for having—thanks for being here, Jay. So, Jay, I invited you on because I wanted to talk specifically about a problem that I first encountered, oh, I’m gonna guess seven, eight, nine years ago or more, and I called it cloud sprawl. Which is, you know, the nice thing about Amazon and AWS is, it made it so easy to spin up new instances and add new storage and what have you. The not so nice thing about AWS and those kinds of things is, it made it so easy to spin up new instances and storage and those kinds of things.

    So, it was—it’s come to the point, Jay, where I know many, many companies really have little control and even less insight into what they’re actually spending on, and what they actually have in terms of assets in the cloud. You know, and for anyone who’s gotten an AWS bill or tried to go through an AWS bill, my AT&T wireless bill is probably easier to understand, if you can believe that.

    So, it’s a real problem. Jay, I would imagine this is something that you guys are helping companies with an awful lot, and that’s the crux of it.

    Chapel: Yeah, that’s correct. I think there’s three problems we primarily see with customers that relates to Amazon, Azure, Google, and/or even multicloud. One of them obviously is what you just brought up, sort of cost visibility. A second, though, is once you get the visibility, it’s around control.

    So, I get a good view of what I have, how do I control those costs using things like reserved instances or turning things off and on. And then the third thing is, really automating that as part of your DevOps process. So, how do I automate that as part of how I’d spin things up in the cloud, spin things down, and really make that integrated into my infrastructure.

    Shimel: So, and hand in hand with automation, we tend to think once stuff is automated, we can reduce the cost of it, but we really can with automation and on and off stuff. You know, Jay, and we can talk later perhaps on another DevOps Chat, we can get into the kinda technical details of how this all works.

    But I wanted to focus our conversation today really at the business owner or business stakeholder, if you will, who is tasked with keeping a cloud budget on budget or under budget, who is tasked with making sure that there’s enough resources to do what needs to be done, but not—they don’t have excess resources—who really is, I mean, this is a major problem for them.

    Without naming names, Jay, can you give me some war stories, if you will, of kinda the worst messes you’ve seen some companies get into before they came over to ParkMyCloud?

    Chapel: Yeah, so, I mean, to your point around the business owner—so, we just talked to a large company yesterday that’s moved into AWS, and they actually had a team of people on the phone with us, I think there were five or six of them, and they all had cost management or cloud reporting or some kind of financial control in their title, even though they were technical people. So, people are—companies are putting people sort of in charge of this problem and spending money to help manage and reduce money.

    So, that’s a really large company with lots of resources, but then, for, I would say, companies born in the cloud, like whatever fintechs or health care or social media or ad companies that have been built over the last five or 10 years with all their infrastructure in the cloud, to really put that responsibility more on sort of the DevOps person.

    So, it’s kinda interesting as, even though they’re technical, they’re also responsible for controlling cloud costs, because somebody’s knocking on their shoulder saying, “Hey, this bill’s gone up. You need to manage this. Here’s a visibility into that—now you need to put controls and mechanisms in place so people just can’t spin things up randomly, and there’s some process in place.”

    So, it’s kind of a mix based on the size of the company, for sure, but that’s definitely a problem we see, and those are the people we talk to every day.

    Shimel: Absolutely. So, Jay, I don’t know if you guys have amassed any kind of metrics or anything, but give me a size of a company and kinda what their cloud bills are. And there’s probably a difference between native cloud and companies who are just starting to kinda go through their transformation. But what—you know, just so we have a kind of field of reckoning, what kind of budgets are we talking about?

    Chapel: Yeah, well, that’s an interesting one. So, lots of people you actually talk to on the phone don’t really know how much they totally spend per month on the cloud. [Laughter]

    Shimel: Oh, I know that.

    Chapel: But they do know the size of the infrastructure, so they’ll be able to tell you, “Hey, we’ve got 4,000 instances, and I’ve got this much in storage, and I’ve got this much in terms of database spend,” and things like that. But they really don’t know their total bill.

    But we talked to—we just talked to a company today with 4,000 instances, another one the other day with 7,000, another one the other day with 12,000. So, it’s really all over the map, but if you have 12,000 instances, you’re spending millions of dollars per month with either Amazon, Azure, or Google—in this case, it happened to be Amazon.

    But the more interesting thing is that, what we see is like—for a really good example, we’re just looking at a company today based in Canada that uses our platform, they have about 430 instances in Amazon, and they park 26 of those, but they save $18,000 a month just by parking 26 of those.

    So, what’s interesting is how big the instance is and then how much money you can save on it. So, if it’s a small or micro, you’re not gonna save much money, but if it’s a database and/or a large, extra-large, you know, the gargantuan instances, you save a lot of money on those.

    So, it’s really all over the map on how much you spend based on not always the instance count, but the size of those instances or databases you’re running in the cloud.

    Shimel: Got it, got it. It’s a crazy—I mean, when you think about it, the fact that they don’t know what they’re spending, Jay, and they have—you know, you’re talking to someone who, when I used to have to put a new server in would grab a screwdriver to rack mount it, right? [Laughter] So, 400 is a lot of screws.

    Chapel: Yeah. [Laughter]

    Shimel: But the fact that they don’t even know what they’re spending, I mean, at some point, that’s almost negligent, right? But yet, I get it. I get it, because it’s hard to put it all together.

    Chapel: Well, it’s hard to put it all together, but then, you know, it also depends on who you’re talking to. If you’re talking to the CFO or the CIO or CTO, they probably understand quote-unquote how much they’re spending in the cloud. But, as you move down the organization to DevOps engineers or IT operations or director level, they may or may not know the total bill, but they definitely know what they’re responsible for in terms of infrastructure. And then, more importantly, how are they charging that infrastructure back?

    So, we talked to some companies that do a pure chargeback model and they even do a cost uplift. So, let’s say that some organizations spend $100,000 a month in the cloud—well, they’re actually gonna cost uplift that and say, “Okay, well, I’m gonna put 10 percent on this or 20 percent on this for managing that for you.” And we talked to some companies that have no chargeback at all, that IT just pays the entire bill.

    So, it really—you know, it’s really very similar to a traditional data center in that sense; so, just depending on the way people put their cost models internally and if they charge it back to projects and stuff. Definitely very interesting conversations when you get to it with people.

    Shimel: Absolutely. Jay, just while we’re here, though, why don’t you give a little background on ParkMyCloud, though? I realize we didn’t really do that before, so what exactly—you know, give us a little background.

    Chapel: Yeah, sure. We’re a two-year-old company based in Northern Virginia. We’re right near Dulles Airport, if people know where that is. And basically, what we do is, we help people optimize their cloud costs by turning things off when they’re not being used.

    So, you could take a simple example of a customer that has maybe 100 instances in the cloud, maybe 55 of those are production and 45 of those are non-production. Well, those non-production instances generally don’t need to run on nights and weekends, and then we help them identify those instances, automate the sort of shut-down process based on schedules, and then bring them back up when they’re needed. And this is all integrated with single sign-on technologies like Slack and Jenkins audit logs and reporting, so it’s really an enterprise technology, and it even has an RBAC model that allows people to set up users teams, so you can do a whole role-based access control around that.

    But when you park an instance, the average savings on an instance is usually between 65 and 70 percent per instance per month. So, ergo the example earlier where this company is parking 26 instances and saving $18,000.00 a month. You can really get a significant ROI doing that. And we have a lot of large enterprises using the platform—Capital One, Unilever, McDonald’s, etc. They’ve been on the platform for a very long time, and we have born in cloud startups like ParkMyCloud using it as well. We do have customers all over the world now in about 15 countries.

    Shimel: That’s pretty amazing. Really amazing story. And Jay, what about you? What’s your background?

    Chapel: Yeah, so I’m a sales guy by nature. So, I’ve been in the IT industry since the year 2000. I used to work for a company called Micromuse. They had a product called Netcool, so if people are familiar with traditional data center service assurance, network assurance, etc. And then we got acquired by IBM Tivoli in 2006, and I spent a lot of time over at IBM.

    And funny enough, in about 2010, 2011, 2012, we were in Tivoli inside IBM and we sold infrastructure software like server monitoring, application monitoring, storage, and stuff like that. And we started losing stuff to born in cloud companies—companies like ServiceNow, companies like Splunk, companies like New Relic and AppDynamics, even solar ones and stuff like that. And what we—you know, and SaaS technologies.

    So, really got into seeing, okay, how are people gonna use the cloud, and then where is that gonna go over time? And obviously now, since it’s a utility, really, we really kind of turned ParkMyCloud into something that focuses on cost control and optimization. Sort of like Nest for the cloud—that’s how we got to where we are today.

    Shimel: Very cool, man. So, as I mentioned, Jay, we’re gonna have you and the folks on again, because I want to get more into the technical aspects of all of this. But I think what we’ve given people today is a good overview of the business case on why—I mean, if you don’t know what you’re spending on cloud to begin with? Call, right—give a call over there.

    If you don’t know how many instances you have or, you know, are you shutting stuff off automatically, or is it simply if you’re just wanting to automate this, right? Because this is really something that, to me, screams out to be automated—really, ParkMyCloud seems like a great solution that you should be looking into.

    Chapel: Yeah, it’s a single purpose platform, built solely to help people optimize inside AWS, Azure and Google. And we offer a free trial, and it’s, most of—I would say at least 75 percent of our customers are 100 percent self-service. So, we’ve never talked to them, they pay a subscription, they save money, and they love using the technology.

    Shimel: That’s a nice business right there, my friend. Alrighty!

    Hey, Jay Chapel, CEO, Co-founder of ParkMyCloud—thanks for being this week’s guest on DevOps Chat, and we look forward to hearing more about ParkMyCloud in the future.

    Chapel: Yeah, likewise. Thanks for the time, Alan. I really appreciate it.

    Shimel: Alrighty. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. We hope you enjoyed this, and we’ll see you soon on another chat.

    — Alan Shimel