devopsy.kinsta.cloud

Category: DevOps in the Cloud

  • Kentik: Cloud Native Applications Need Network Analytics

    Kentik: Cloud Native Applications Need Network Analytics

    Moving everything into the cloud seems to have taken the spotlight from the network. As the internet is ubiquitous, who worries about the networks? Kentik has a notion that in the age of cloud native, network analytics are as important as ever. In fact, network analytics may be more important than ever.

    I sat down with Jonah Kowall, CTO of Kentik, to discuss this issue. Of course having Jonah here in our Digital Anarchist studios, allowed us to explore some other areas including Jonah’s experience as a Gartner analyst, and then working at AppDynamics.

    Kentik is doing some really interesting things around network analytics to help app performance and even security. The use cases for this are pretty broad. From edge, to cloud (multi-cloud and hybrid), data center and containers, Kentik has a great use case.

    With so much going on with NewOps, NoOps (I hate this one), AIOps, DataOps and more, it sure does seem like Ops is the place to be these days. On top of this, as much as things change, it seems that what’s old is new and no matter what, the network still matters.

    Have a listen as Jonah explains further:

     

    — Alan Shimel

  • HPE Extends Hybrid Cloud Computing Strategy

    HPE Extends Hybrid Cloud Computing Strategy

    Hewlett-Packard Enterprise (HPE) today advanced its hybrid cloud computing strategy by announcing at its HPE Discover 2019 conference an alliance with Google to embrace Kubernetes in hybrid cloud computing environments and then extending the reach of its software-defined infrastructure for building private clouds to legacy ProLiant servers.

    Lauren Whitehouse, director of marketing for the software-defined and cloud group at HPE, said the HPE Composable Cloud now extends beyond new ProLiant servers to include everything from legacy hardware to cloud computing platforms running virtual machines or as bare metal servers optimized for Kubernetes.

    To achieve that latter goal, HPE will make it possible to deploy Google Anthos, a previously announced framework for delivering cloud-native computing services across public clouds and on-premises IT environments, on HPE-managed platforms.

    HPE is giving customers the option of deploying configuring local servers with virtual machines with either a VMware vSAN storage software or the HPE SimpliVity hyperconverged infrastructure platform. Additionally, customers can choose to deploy Kubernetes on those platforms or run Kubernetes on a bare-metal server. On top of those stacks, HPE also embeds the HPE OneView IT infrastructure management and HPE Composable Fabric networking solution to create what the company calls a composable rack environment.

    Finally, HPE announced it will extend the reach of the HPE InfoSight artificial intelligence engine, which it gained for storage environments when it acquired Nimble Storage, to the rest of its data center portfolio.

    Whitehouse said that, by extending the reach of its composable computing strategy to include legacy servers, HPE seeks to make it easier to modernize on-premises IT environments within the context of a larger hybrid cloud computing strategy.

    One of the primary reasons so many workloads are being deployed in the cloud is because of the inherent flexibility of the IT environment. HPE is investing in higher levels of infrastructure abstractions to enable an equivalent amount of agility to be injected into on-premises IT environments. Those efforts will then make it easier for organizations to extend best DevOps practices across a hybrid cloud computing environment, said Whitehouse. The company is now removing the objection by organizations to have to implement a forklift upgrade across their entire on-premises IT environment to achieve that goal, she added.

    It’s not immediately clear who will manage what in this brave new world of hybrid cloud computing. Application developers have been exercising a lot more influence over platforms, while advances in automation appear to be heralding a consolidation of management functions within the local data center. As site reliability engineers, or so-called “super administrators” capable of managing compute, storage and networking infrastructure continue to emerge, the silos around job functions in the enterprise were built are breaking down. In fact, the more organizations embrace DevOps best practices, the faster consolidation of job functions is occurring.

    In the meantime, whoever provides the infrastructure that remains in an on-premises IT environment had better be able to enable local IT teams to be just as flexible as any cloud service provider an application developer is likely to encounter.

    — Mike Vizard

  • Lessons Learned From the Salesforce Outage

    Lessons Learned From the Salesforce Outage

    Everyone has bad days. Every company has been through some kind of outage due to a buggy database deployment. Even the best of the best, with highly trained staff, world-class best practices and well-thought-out processes make mistakes. On May 17, Salesforce.com had a bad day.

    What Happened?

    The company deployed a faulty database change script that broke permission settings in production and gave users read and write access to restricted data. This opened the door for an unauthorized employee to steal or tamper with the company’s data. As a result, Salesforce needed to take large parts of its infrastructure down to find and properly fix the issue. The outage lasted 15 hours, 8 minutes. According to Gartner’s cost-of-downtime formula ($5,600/minute), this outage cost approximately $5 million. Plus, since so many companies rely on Salesforce, it was a very visible and embarrassing outage. (Just take a look at #SalesforceDown and #permissiongeddon on social media.)

    Salesforce had to shut everything down because of the way databases work. It’s not as easy as pulling a single application. Who knows how many Salesforce employees worked like mad to take the whole database down, find the offending database script, and restore everything—all because of one change script. That’s not a fun way to spend a weekend.

    What Does This Tell Us?

    Historically, Salesforce customers have experienced very little disruption in service. On the day of the outage, many loyal customers were tweeting about how rock solid the service has been, and that’s impressive.

    That being said, this outage should be a wake-up call for users to realize their dependency on their platform, which has become a more integral part of how we conduct business. I’ve heard anecdotes of entire offices being unable to complete work that Friday.

    The customer reactions show that they clearly have their stuff together over at Salesforce. What this outage shows is less about any shortcomings of this company specifically; but rather that everyone has blind spots, no matter how robust the testing process is.

    Lessons for IT professionals:

    • Don’t forget the database. Unfortunately, this problem is all too common. There are countless cases of a database change script being executed in production and causing unexpected issues. This indicates that the database is often the forgotten part of the software test and release cycle. Unless companies start to seriously consider the database when it comes to change management, things like this will continue to happen.
    • Automate everything. Manual efforts fail. Humans make mistakes. Companies such as Salesforce that handle sensitive customer data should not put it on the internet unless they have automated every aspect of the system, including the database. Companies need a robust DataOps process, one that includes production-like data and automates the validation database changes.

    Lessons for end users:

    • Establish a continuity plan. Organizations that depend on systems such as Salesforce need to have a business continuity plan to continue operations if they go down. This includes syncing Salesforce tasks and calendar with Office365, Exchange or Google Apps. However, since Salesforce has become the system of record for most companies that use the technology, having a backup of the data will be very difficult—after all, the point of a company using the platform in the first place was to avoid hosting its own data.
    • Demand accountability. Additionally, users can and should demand more accountability from software vendors. This can take the form of demanding a refund, but also customers need to speak to their account manager to understand what steps Salesforce is doing to make sure this does not happen in the future. It’s 2019 and companies update software all the time without taking down their production systems at the end of a quarter. Moreover, companies also can demand that companies don’t change production systems, outside of necessary security issues, during business hours.

    The bottom line is that, while the mistakes that led to the Salesforce outage are very costly and highly visible to customers, they are also entirely preventable.

    — Robert Reeves

  • Portable Security Policies: A DevSecOps Primer

    Portable Security Policies: A DevSecOps Primer

    Protecting critical data and applications is a challenge under any circumstances, but it’s especially daunting when resources reside in the cloud. Most organizations today operate a significant portion of their workloads in the cloud, which adds to the complexity of the security problem—a security team can’t fully control cloud environments but is responsible for securing workloads and applications running there.

    Cybercriminals are exploiting the situation. They’re becoming more aggressive and ingenious in their efforts, taking advantage of the fact that there is confusion about who is responsible for which aspects of security under the Shared Responsibility Model. Adding to the chaos is the differentiation between cloud providers’ security offerings and capabilities. Quite simply, in most cases, cloud providers are responsible for the security of the cloud and consumers are responsible for security in the cloud, meaning that security and networking teams still need to ensure their organizations’ workloads and applications are free from malware or other tampering.

    To accomplish this, security and networking teams can’t rely solely on firewalls, threat detection and vulnerability patching to secure vital digital assets. Security tools developed for traditional data centers are not effective at securing workloads in the cloud due to the cloud’s dynamic nature. Security and networking teams must rethink their approach.

    Unfortunately, many organizations are still relying on old and ineffective strategies—further hardening the perimeter, investing in additional threat detection and adding new tools and controls that focus on identification rather than prevention. This security approach has its place, but it does nothing to prevent malicious actors from moving laterally across the network once they achieve a foothold, which leaves cloud-hosted apps and workloads extremely vulnerable.

    Instead, security teams need to enable zero trust in cloud environments, which treats all internal communications as untrusted by default. With zero trust, only authorized applications and services are allowed to send and receive communications, and only in specific ways governed by the principle of least privilege.

    The Second Layer

    Traditional tools aren’t effective in enabling zero trust in the cloud because security and ops teams have a very limited ability to manage all layers of the cloud’s open systems interconnection (OSI) model. Specifically, the lack of Layer 2 controls in infrastructure-as-a-service (IaaS) environments makes tools developed for discrete networks all but useless for locking down ports and controlling or scrutinizing IP addresses.

    Even if an organization manages to implement these tools in the cloud, it cannot provide the level of granularity required to stop malicious lateral movement. For example, when on-premises tools are repurposed for cloud environments, they usually rely on subnets to define the boundaries of communication. Because cloud subnets are designed to handle elastic workloads, they need to be far larger than those in on-premises environments. As a result, cloud workloads are more exposed than is necessary.

    Securely migrating workloads and applications to a cloud environment is a huge and cumbersome job when relying on traditional tooling. The best way to make workloads portable and secure is to decouple workload protection from the underlying infrastructure. In this way, organizations can be certain that any policies applied on-premises can migrate to the untrusted environment of the cloud, without the complexity of mapping changing network addresses, writing policy exceptions or losing fine-grained control during the process.

    Decoupling workload protection from the network requires abandoning a network address-based approach in favor of one based on identity. By using the immutable properties of workloads, security teams can create cryptographic identities for applications and services, which then can be used to determine what is allowed to send and receive communications. Not only does this model provide stronger security, but it also works regardless of where applications are located, because these identities are unaffected when network elements change. What’s more, they can be constructed to tolerate upgrades. By building identity-based policies, security teams can create microperimeters around applications that follow workloads wherever they go, and the policies verify communication across boundaries every time an application attempts to communicate.

    Implementing network-agnostic policies doesn’t just harden security. Software developers benefit as well. Without the roadblock of translating application-speak to network-speak, developers can build software and applications in any environment favorable to their workflow while defining policies to protect their work. Once the software is built, they can securely deploy the finished product to the production environment—even if it is hosted by a third party.

    No organization should have to compromise security to benefit from the efficiencies offered by the cloud and ephemeral auto-scaling containers. Building identity-based policies that enable zero trust and are independent of the underlying network ensures that companies never have to consider making that trade-off.

    — Tom Hickman

  • How Not to Sabotage Your Multi-Cloud Strategy

    How Not to Sabotage Your Multi-Cloud Strategy

    The immense pressure for enterprises to deliver new applications and insights that exploit new business opportunities has been a driving force for digital transformation. This, in turn, has led IT leaders to embrace a multi-cloud strategy—whether that’s deploying a combination of cloud platforms such as AWS, Azure and Google, or extending private data centers to the public cloud—to achieve greater agility, optimized performance and cost savings resulting from deploying workloads across multiple cloud platforms.

    However, maintaining multiple cloud platforms and services adds complexity and even confusion to enterprise IT environments already crowded with a range of technologies, applications and processes. While a recent Forrester study shows that enterprises are increasing investments in using multi-cloud strategies for business-critical applications and workloads, the majority of these enterprises also report that they experienced issues with deploying and using multi-cloud environments.

    The difficulty in managing IT environments made more complex by multiple cloud services involves three major issues: ignoring the importance of cultural transformation, not addressing the widening skill set gap and implementing a DIY approach to cloud management.

    Here are three ways to deal with these challenges, so you don’t end up sabotaging your multi-cloud strategy.

    Make Culture Change a Priority

    The cultural transformation required to support digital transformation and to fully take advantage of multi-cloud’s power is more than shifting the organizational mindset from capex to opex. It’s also more than picking one or a combination of the big three cloud providers and simply saying, “Let’s do this.” It requires building trust and breaking down the silos of technology knowledge—whether vendor, legacy or emerging technologies—across disparate IT teams to achieve the business goal of speedier application development and faster time to market.

    Specifically, this culture change requires better collaboration between teams and arming central IT with up-to-date processes and management platforms that are focused less on managing infrastructures and more on achieving a balance between visibility and resource control, the linchpin for IT, and creativity, the true north for developers. It will have parameters in place for provisioning resources while helping developers get the resources they need—compute, storage, network services and more—as quickly as possible.

    Culture change also enables the maturing of DevOps processes toward streamlining and bringing order to the clutter and smooth partnerships with other IT teams, especially security and operations. These include processes to eliminate bottlenecks in workflow, to advance automation and self-service, to consolidate resources and to make security integral to—rather than an afterthought in—the development process.

    Invest in Building Expertise in Multi-Cloud and Emerging Technologies

    The more cloud environments an organization has, the more skills and tools are needed to be able to deploy and optimize these environments efficiently. Despite increasing commoditization in the industry, there are still differentiators between cloud vendors and their services, and ways to leverage these to align with an organization’s specific needs. To do this, it is crucial to train the internal DevOps team or hire experts in multi-cloud environments and in key technologies for advancing multi-cloud such as containerization, microservices and serverless computing.

    Additionally, a cloud management platform that provides self-service IT and enables any user to provision, manage and orchestrate IT resources, will allow both end users and admins more time to focus on getting high-quality work done.

    Select a Cloud Management Platform that’s Right for You

    Cloud management platforms address the complexity of hybrid and multi-cloud environments by providing a central platform that allows a selection of the clouds and services that best fit an organization’s needs. They also enable IT to connect to any third-party resource, whether that’s VMware on-prem, AWS in the public cloud or container orchestrators such as Kubernetes, to gather the inventory of cloud computing resources and to provision new resources to be used by anyone in the organization from one place. Self-service IT can also be enabled when appropriate.

    In addition, by ensuring cloud management platforms are built on a single pane of glass, IT can gain a holistic view of hybrid and multi-cloud environments. It also allows effective monitoring of resource utilization across those environments, thus ensuring that cloud spend is not only reined in but also optimized.

    Finally, a cloud management platform should connect both legacy and new technologies within cloud environments. Although the complexity will not go away, it gets easier to manage. Instead of having multiple teams from different departments managing and accessing resources in separate environments, a central team handles complexity with enterprisewide visibility and control.

    The way to succeed is to embrace the complexity by configuring it and managing it behind the scenes, so developers and end users consume IT resources from one consistent way, regardless of where it comes from. Leave the complexity to the cloud and IT architects and let your end users and developers get to work.

    — Brian J. Kelly

  • VMware to Acquire Avi Networks for NetOps Capability

    VMware to Acquire Avi Networks for NetOps Capability

    VMware announced it intends to acquire Avi Networks for an undisclosed price as part of an ongoing effort to close the gap between network operations (NetOps) and DevOps.

    Once this deal closes, sometime between now and August, VMware plans to add a software-based load balancer, along with a web application firewall (WAF) and a service mesh to its network virtualization software portfolio.

    Tom Gillis, senior vice president and general manager for the networking and security business unit at VMware, said the goal is ultimately to make it as simple to deploy applications in an on-premises IT environment as it is on a public cloud by enabling IT organizations to automate the provisioning of network resources exposed via the VMware NSX network virtualization overlay. Avi Networks will extend those capabilities by adding a high-performance programmable load balancer, which eliminates reliance on legacy load balancers based on proprietary hardware platforms that are both expensive and rigid.

    Gillis said VMware will then infuse the WAF technology developed by Avi Networks into its network overlay platform to further secure east-west traffic in the data center.

    Finally, VMware intends to marry the service mesh technology from Avi Networks that supports a high-performance ingress controller with its ongoing efforts to integrate the open source Istio service mesh with NSX.

    Once all that work is completed, Gillis said it should be possible to deploy a workload on any platform with a single click. The challenge organizations face today is that provisioning and securing the network resources required to deploy an application outside of a public cloud computing environment still takes multiple days to sometimes weeks. VMware has already signaled its intention to make NSX network overlays available across multiple clouds and on-premises IT environments.

    Avi Networks CEO Amit Pandey noted that both companies are on a similar trajectory to leverage x86 processors to eliminate reliance on proprietary networking hardware. That shift to software-based networks and security services is driving the biggest transformation in the data center in the last 25 years.

    In terms of leveraging application programming interfaces to automate the provisioning of networks, it’s clear networking technologies have been lagging behind advances made in both compute and storage infrastructure. The challenge and the opportunity vendors such as VMware now see is the ability to more holistically manage IT environments spanning from the network to the application. As part of that strategy, VMware has been making a string of acquisitions to extend its core virtual machine franchise.

    It’s still too early to say whether all those investments will pay off for VMware. Reliance on VMware technologies in public clouds is relatively slight compared to the dominance VMware has today in on-premises IT environments. VMware is banking that its ability to extend the reach of its portfolio to foster the development of hybrid cloud computing, which is strongly anchored around on-premise IT environments that still run the majority of the workloads in the enterprise, will prevail.

    — Mike Vizard

  • RDX Eases Oracle Database Migration to PostgreSQL on AWS

    RDX Eases Oracle Database Migration to PostgreSQL on AWS

    RDX this week launched a set of tools designed to make it easier to convert applications running on an Oracle database to Amazon Aurora, an instance of an open source PostgreSQL database running on the Amazon Web Service (AWS) cloud that is compatible with Oracle databases.

    Announced at the AWS Summit event in Washington D.C., the clckwrk Refactoring Service for Oracle promises to reduce the amount of manual effort associated with refactoring applications for the Amazon Aurora platform by automating as much as 60% of the database schema conversion process.

    James Ball, chief strategy officer for RDX, said in addition to reducing costs, many organizations want to shift applications to open source databases in the cloud to further their DevOps ambitions. Each time an application needs to scale, an organization will incur additional Oracle licensing fees. In contrast, an open source database enables DevOps teams to scale database instances as required automatically, he said.

    AWS has been making a concerted effort to convince customers to give up proprietary databases in favor of open source databases running on its cloud platform. That competitive pressure is a driving force behind new alliances that previously would have been considered unimaginable. Oracle, for example, recently partnered with Microsoft to promote the integration of the Oracle Cloud platform with the Microsoft Azure cloud. Oracle would prefer its database run on its cloud, but through the alliance is signaling its willingness to work with Microsoft to deploy Oracle database on Azure, a cloud platform that is the leading industry alternative to AWS. Microsoft, of course, has its proprietary database to adopt in the form of Microsoft SQL Server.

    Ball said RDX not only provides tools to accelerate the conversion to Amazon Aurora, but it also provides managed services for customers that want to outsource the management of Amazon Aurora to RDX.

    It takes most organizations several months to migrate a legacy application on to a public cloud. AWS has a vested interested in helping accelerate that process whenever possible. But many organizations that have embraced best DevOps practices find their efforts are hampered by reliance on proprietary databases. In fact, one of the reasons so many developers tend to favor open source databases is to avoid all the headaches associated with getting approvals for new database licenses.

    It’s unclear to what degree the rise of DevOps in the enterprise will ultimately shift database allegiances. Oracle is trying to maintain as much control as possible by making its databases available as a managed service that eliminates some of the purchasing overhead associated with spinning up new instances. However, the cost of an Oracle database license is still buried in the cost of the managed service.

    Not every organization is looking to transition away from a proprietary database, but there is now enough momentum around the “open source first” movement to make it worthwhile to build tools that automate the refactoring of legacy databases not just to reduce costs, but also to make IT a lot more agile.

    — Mike Vizard

  • Akamai Extends Reach to the IoT Edge

    Akamai Extends Reach to the IoT Edge

    Akamai today unveiled a strategic initiative to extend the reach of its global network out to applications deployed on the network edge.

    Announced at the Akamai Edge World conference, the Edge Cloud portfolio will consist of a mix of existing, new and forthcoming offerings. In terms of new offerings, Akamai launched IoT Edge Connect, which provides access to the Message Queuing Telemetry Transport (MQTT) protocol that gives internet of things (IoT) applications access to a publish-and-subscribe service. Akamai claims IoT Edge Connect will scale to support hundreds of millions of endpoints and is capable of processing 10 times more messages than other IoT or in-app messaging cloud solutions. Those capabilities not only will optimize data delivery, but also should also reduce the amount of power devices will need to send messages, according to the company.

    Scott MacGregor, senior director of engineering at Akamai, said IoT Edge Connect will join Akamai Over The Air (OTA) Updates, an existing service for updating applications using a wireless cellular network, in the Edge Cloud portfolio. Those two offerings will be joined in the future by a key-value store that will make it possible to store data on a local IoT gateway and a tool for running functions on an IoT endpoint, he said.

    Akamai intends to provide the same capabilities it makes available to web applications to a new generation of edge computing applications that need access to a global network, MacGregor noted. In some cases, the data those applications need to access will be stored on local gateways. In other cases, the data being accessed will be stored within the network managed by Akamai. DevOps teams tasked with building IoT applications would view the Akamai network as just another platform they need to push code to from whatever continuous integration/continuous deployment (CI/CD) platform they choose to employ, he said.

    In general, MacGregor said many organizations underestimate the challenges associated with building and deploying distributed IoT applications at unprecedented levels of scale. IoT applications that span global networks are challenging to build, and the processing occurs at the edge, on local gateways and in the cloud.

    Akamai, of course, is not the only provider of a global network looking to entice organizations to leverage their infrastructure to deploy edge computing applications. Everyone from carriers including AT&T and Verizon to cloud service providers such as Amazon Web Services (AWS) and Microsoft are making similar cases. It’s too early even to hypothesize which platform providers might ultimately triumph. Akamai, however, is counting on its relationships with developers to become an edge computing force to be reckoned with, said MacGregor.

    Akamai made its mark in the enterprise by providing a global content delivery network (CDN) that web developers leverage to extend the reach of their applications by leveraging cache memory Akamai makes available on a global network. Since then, the company has been extending the service to include a range of security services that isolate web applications from various potential threats. If Akamai has its way, those same services soon will be pervasive across a broad range of edge computing applications.

    — Mike Vizard

  • Why Your Test Automation Is Failing

    Why Your Test Automation Is Failing

    If you have been investing in test automation, but it’s not getting you where you think it should, it could be that you approached it superficially.

    One of the most common issues is that the test part of test automation is rather straightforward to automate, especially with today’s abundance of great automation tools. But jumping straight into automated testing leaves you with a big heap of automation scripts, and often not the best ROI. Understanding why requires looking into the automation process.

    When an engineer builds an automated test, they do it in a test environment that they (or someone in the organization) set up. Usually, this is the same way manual testers get access to test environments.

    Before the engineers start automating, they have a working copy of the product they are testing, with relevant data on it. They have a good idea of the test they want to write. Everything looks promising.

    They write the test and give it a few runs. Everything is looking nice and stable. Now, to provide the ROI we were hoping for, the test must run a million times. Or, at least, a few thousand times, right?

    To reap the benefits of automation, it needs to happen frequently enough. However, the bottleneck is often discovered after creating a bunch of tests. Because the tests must run on a similar test environment to the one used to create them, with the new versions of the product or with any introduced changes that are being tested, you need access to hundreds of environments. This requirement makes it difficult to test effectively.

    Below are three test environment approaches that inhibit test automation.

    Manually Setting Up an Environment Each Time to Run Automated Tests

    For tests that don’t need to run as frequently, such as security testing and performance testing, it’s common to set up an environment for automated tests every time the test needs to be executed. As a result, testers must wait for the environment to be ready, perhaps do some additional configurations and then run a suite of tests. And, if they’re trying to optimize utilization, the environment is left to run overnight or weekend.

    The problem with this approach is it takes the “auto” out of automated testing. When automation depends on a manual step, the test is only as efficient as this manual step.

    If the manual step isn’t very efficient, automation may not be helping at all. I’ve seen companies take so long to get an environment to work that running automated tests on it didn’t make any difference from a time perspective.

    Setting Up a Static Environment That Automation Always Runs On

    When setting up an environment takes a long time, it’s natural to assume it’s worth leaving an environment running so test automation can run on it. The preparations were made, the infrastructure is all in place, the product is configured and the data is ready, so let the automation party begin.

    While complex, static test environments may seem ideal, but the party doesn’t last long. First, since it usually takes some time to put the environment together (same as the previous case), it often becomes high-maintenance. It can be scary to make changes that could ruin things, and you can end up needing someone to manage change full-time. Much like chocolate cake in the office kitchen, an environment that mimics production with good data on it tends to attract everyone. Soon, these nice environments become shared assets and tests start conflicting for the same resources. The natural next step is to set up another static environment. This loop usually ends with an angry manager saying something about cutting CAPEX.

    Automating the Environment and Cutting Ourselves Some Slack

    With the rise of infrastructure as code (IaC) and immutable infrastructure, there are more ways to spin up a test environment. Resourceful test teams will try to automate the environment creation or use built-in test tool or CI system capabilities to run tests on a public cloud instance or a container, if the product they test allows that. This is cheap and useful—and could work for some simple tests. The challenge usually starts with everything this approach doesn’t cover. It can be difficult to use IaC to spin up a test environment and handle all aspects of it—from security and isolation to dependencies, data, third-party integration and more. This is where this approach is often blocked and sends us back to the previous two approaches for a big part of the testing load—which again makes test automation investment less fruitful.

    The Right Way to Set Up Test Environments: Test Automation on Dynamic Environments

    The test automation world needs a game changer. You can make your car faster, but if the road is full of potholes, you won’t be able to get that fast or far. Test automation is similarly limited by the pace of environment creation, with its infrastructure, application, data and all.

    This challenge becomes critical when adopting DevOps and testing stops being a stage in the pipeline, instead becoming an overall pipeline service. QA is no longer about being the gate between development to operations. It’s about overseeing the quality of the product during its entire life cycle. This means automated tests should always be able to run, and the environment they run on must be dynamic.

    The solution to this challenge is environments as a service (EaaS). EaaS is all about packaging the environment, including the application, infrastructure and data, as an entity that can be provided as a service to a business process. Once defined, it can be provided on-demand for manual or automated users. Since it’s a well-defined entity, it also can be decommissioned when the process finishes using it. Playing an important role in making infrastructure horizontal, EaaS is also the key for paving the road for brilliant test automation.

    If you think you should get more from your test automation initiative, it may be a good time to make EaaS part of your automation strategy.

    — Maya Ber Lerner

  • Which Desktop OS Is Best for DevOps?

    Which Desktop OS Is Best for DevOps?

    Which operating system (OS) is best for DevOps engineers to use on their workstations?

    That’s a weighty question. Talk about which OS is “best” for any purpose is always controversial.

    I’m not going to stick my neck out by saying that one OS is definitively better than others when it comes to doing DevOps work. But I would like to consider the strengths and weaknesses of each of the major desktop operating systems—Windows, Linux and macOS—for performing DevOps work.

    Windows

    Statistically speaking, Windows is the OS that most people use. By extension, it’s the OS that most DevOps engineers probably use. (I can’t confirm that fact, because I’ve yet to see a study of which OS DevOps engineers actually use.)

    As I see it, Windows has two main advantages from a DevOps perspective, including:

    • Popularity. This is a strength because DevOps is all about having freedom to pick and choose which tools to use. Given that Windows is so popular, almost everything is compatible with it. OS compatibility problems, therefore, don’t get in your way of doing DevOps as you see fit.
    • The Windows subsystem for Linux, which lets you run some Linux CLI tools on Windows. This feature is handy if you need to do DevOps work for both Linux and Windows server environments.

    The main drawback of relying on Windows is that, well, it’s Windows. Compared to Linux, Windows offers very little opportunity to customize, and that restraint can be a drawback from a DevOps perspective. When it comes to core tasks, such as working from the command line, you’re stuck with the tools Microsoft offers you. And you can’t do very much to harden your Windows system for security purposes.

    Linux

    For my money, Linux is the best OS for DevOps. But I say that only because I’m a die-hard Linux lover and I tend to think Linux is the best for everything.

    But even if you are not a Linux fanboi, you have to admit that it has certain advantages for doing DevOps work:

    • Linux is ultra-customizable. You can choose to set up your system in whichever way works best for your workflow. You can use a wide array of tools. You can make lots of changes to add extra security. Given that DevOps values choice, this is a big benefit.
    • In many cases, DevOps engineers are supporting software delivery pipelines that deploy to Linux server environments. Being able to work from a native Linux environment can make it easier to do things such as test and stage those applications on your local device when it becomes necessary to do so. You could, for example, spin up a Linux container on your local machine, which you couldn’t do with a Windows or macOS workstation.
    • On most mainstream Linux distributions, installing all of the DevOps tools you need is extremely fast and simple using repositories and package managers. It’s not exactly difficult to install most DevOps tools on other systems, either, but I don’t think any OS can beat the package management systems used by Linux distributions.

    Linux’s major limitation is that learning it takes some time, particularly for DevOps engineers weaned on Windows. You also run the risk of needing a tool that doesn’t support Linux, although I’m having a difficult time thinking of any DevOps tools that doesn’t work on Linux systems.

    MacOS

    Last but not least is macOS. Overall, I don’t think macOS is ideal for doing DevOps work. The only strength I can think of is:

    • It gives you a native Unix-like environment. You can’t run your Linux containers directly on a Mac, but you can at least use some native Unix tools.

    Drawbacks for macOS are many. It’s not very customizable. It lacks compatibility with some applications and tools. It comes with its own learning curve if you have never used a Mac before.

    Does OS Choice Even Matter?

    Now that I’ve weighed the pros and cons of Windows, Linux and macOS as operating systems for DevOps engineers, let me state the obvious: It’s 2019, and in many respects it no longer really matters which OS you run on your local machine. Lots of applications—including key DevOps tools, such as IDEs—now run in the cloud as often as not. Plus, there are a plethora of hardware virtualization tools out there that will let you run virtually any OS in a virtual machine within another type of OS. You can run Linux and Windows side-by-side as virtual machines on your Mac, if you want.

    Still, not everything runs in the cloud, and having to switch between virtual machines is not always practical. It’s therefore worth thinking hard about which desktop OS will best serve your DevOps needs and making that the one that controls your bare metal.

    — Chris Tozzi