devopsy.kinsta.cloud

Tag: cloud

  • Despite Cloud Adoption, Enterprises Demand On-Premises Software

    Despite Cloud Adoption, Enterprises Demand On-Premises Software

    A recent report from Dimensional Research reveals that the demand for on-premises software is equal to that of public cloud. The report, which was commissioned by Replicated, a company specializing in on-premises software modernization, queried 405 participants in software development, executive, product management, sales and services roles to determine the needs, usage and challenges of on-premises software.

    The report revealed that some 90% of companies surveyed said their on-premises sales of software solutions continue to rise, while 70% that do not currently offer on-premises solutions intend to in the near future. 

    “In the past few years we’ve experienced a steady increase in interest from leading global companies who see that modern on-prem software delivery through containers and Kubernetes can make data protection and security much easier,” said Grant Miller, co-founder and CEO of Replicated. “Coupled with growing customer demand, it’s a win-win scenario for any industry.”

    While Miller’s view may be optimistic, the survey also revealed that the majority (65%) of companies cited privacy compliance as the top reason for using on-premises software delivery; an indication that the market is being influenced by cybersecurity issues more than any other factor. However, 54% also stated uptime and reliability were a primary driver for on-premises solutions, while 45% noted the importance of integration.

    The report indicates that enterprises, which have cited digital transformation and a movement towards the cloud as critical factors over the last two years, may also be thinking more about on-premises solutions in light of cybersecurity and compliance concerns. This, in turn, means that DevOps has the potential to gain even more traction in the enterprise. 

    While the report mentions the merits of an on-premises software strategy, it does raise the question of why more enterprises have not moved in that direction already. That hesitation to re-embrace on-premises software can mostly be attributed to perceived complexity, time commitments and the cost of engineering resources to make it happen. 

    Complexity is further highlighted by 74% of survey respondents reporting that it would take more than a week to install and configure on-premises software, and 29% stated an install could take over two months. For the 16% that claim they can rapidly install and configure on-premises software in less than a week, the potential for growth in the market is notable. 

    While the future remains somewhat uncertain, the report from Dimensional Research runs counter to other reports, such as a Synergy Research Group report that revealed in 2019, spending on cloud platforms edged past the resources spent on acquiring servers and software for on-premises data centers. “60% of the servers now being sold are going into cloud providers’ data centers and not those of enterprises,” said John Dinsdale, a chief analyst at Synergy Research Group, confirming the trend. “Clearly, companies have been voting with their wallets on what makes the most sense for them.”  Dinsdale said the growth of cloud infrastructure will continue to accelerate aggressively over the next five years. 

    Although conflicting observations tend to add to the market confusion, one thing is certain – DevOps shops have market opportunities to service customers deploying both to the cloud and on-premises software.

    on-premises

  • ‘Old Man Yells At Cloud’

    ‘Old Man Yells At Cloud’

    These days, software programmers are increasingly estranged from hardware. Most millennials and Generation Z developers have never had to mount physical servers. They have never been lulled by the gentle hum of a server room chugging along in synchronous harmony. Today, you don’t even necessarily have to build your own PC or worry too much about disk space.

    Instead, cloud-native software developers conveniently offload the server burden to cloud service providers (CSPs). Hosting in a cloud, like AWS or Azure, for example, makes a lot of sense — it allows programmers to hone in on their own specializations. Elastic computing models are cost-effective for startups, and CSPs typically offer a vertical stack with helpful integrated platform-as-a-service (PaaS) and software-as-a-service (SaaS) offerings. However, what are we sacrificing?

    Well, first, research shows the cloud model becomes less cost-effective as a business scales. Second, as more companies transform into technology platforms, cloud usage could better enable their competition. Third, more direct access to bare metal could be an attractive option for certain service providers to increase ownership and control workload optimizations.

    These arguments are bolstered by large companies such as Dropbox, Facebook, Walmart, and others that chose to cut their cloud allegiances in favor of building their own data centers or adopting colocation (in other words, running your own hardware in someone else’s data center, also known as “colo”).

    I recently met with Zach Smith, managing director, bare metal, Equinix, to understand the current state of hardware-as-a-service and the future of hybrid server models. He believes that in the coming years, improved interfaces that access low-level infrastructure will arm IT with better consumer choice that brings them closer to the metal. Yet, to enable this, the hardware world will need to take some lessons from the upper stack regarding transparency, open source community, programmability and improved developer experiences.

    Sidestepping the Cloud

    Public clouds arose as a convenient one-stop-shop to host entire software application environments. As a result, “we have a generation of developers who will never physically touch that hardware,” Smith said.

    The cloud infrastructure services market was worth $39.8 billion in Q4 2020, estimates according to estimates from Statista. Having witnessed the “movement toward verticalization of hyperscale clouds,” Smith now sees the infrastructure-as-a-service (IaaS) market as an industry of high margins and escalating fees. This is echoed by others who seek to reduce rising cloud expenses.

    Though cloud computing usage is growing considerably, the data center isn’t dead. Instead, computing models are morphing and becoming hybridized. “By 2025, 85% of infrastructure strategies will integrate on-premises, colocation, cloud and edge delivery options, compared with 20% in 2020,” predicts David Cappuccio, distinguished VP analyst, in a Gartner report.

    As hybrid multi-cloud approaches emerge, Smith notices a resurgence of attention being paid to infrastructure. Some massive service providers are starting to construct their own data center estates; others, such as Box, now own and lease servers from data center providers.

    Benefits of Bare Metal

    As mentioned above, there are a few reasons to move back to the metal. First, it may simply be more cost-effective for large deployments. In his well-researched article, Antoine Beaupré compared monthly recurring costs for colocation versus an AWS bill, and found the break-even point rested at $100,000 per month, or 150 Amazon m4.2xlarge instances. His research also found that I/O-heavy applications are more costly in the cloud than via colocation.

    “While many services simply launch in the cloud without the organizations behind them considering other options, large content-hosting services have actually moved back to their own data centers,” Beaupré said.

    In addition to cost savings, automating colocation with a programmable layer could also offer more fine-grained control over computing optimizations. “I believe what we’re creating is an operating model for a rapidly changing hardware substrate,” said Smith. He described how bare metal opens up a neutral infrastructure substrate to control physical networking aspects such as cross-connects, IP transits and peering — a benefit Smith half-jokingly called ‘NetDevSecOps.’

    Another argument is that investing in hardware could, ironically, bring sustainability benefits. A report conducted by ITRenew estimates that, of the total embodied energy required within a server’s entire lifespan, 77% is used to manufacture the hardware itself. In contrast, the operational energy used over a server’s lifetime only accounts for 22%.

    Thus, there is an environmental benefit to reversing the trend of a make-dispose economy continually producing new servers. Instead, hardware ownership could encourage a more circular economy. “A circular economy aims to end our take-make-dispose economy, which is a very linear approach, and instead, keep products at their highest possible value for as long as possible,” according to the ITRenew report.

    Learning From the Upper Stack

    How can we build a fundamental non-opinionated infrastructure platform? According to Smith, the industry needs “hardware and networks that are programmable and usable by a developer generation.” To Smith, changing firewalls at a kernel level, altering how the runtime works or controlling the IP stack, should all be operational via API commands.

    Yet, hardware accessibility is still rather opaque and, historically, not as developer-friendly. “How can we take abstraction and community-driven ideas from up the stack?” Smith asks. To enable these changes, he believes the hardware world should model itself on the upper stack in a few key areas:

    1. Transparency: The hardware world is not as easy to comprehend. “When you get to the physical side of switches and routers, it’s still arcane,” Smith said. Increased transparency in functionality and ownership will be required to turn servers into something all developers can operate.
    2. Open-source community: In the same way the software world is built on strong developer communities, hardware will require an open community to normalize things like firmware, boot order and support for differences between drives.
    3. Programmability: “Self-service and programmability are requirements for most things these days — there’s no difference with physical infrastructure,” says Smith. Take the rise of the API economy — today’s mantra is, essentially, if something is possible in a UI, it should be possible through an API. Similarly, if it can be done in a server, it should be controllable with an API.
    4. Quality developer experience: Self-service, programmable infrastructure is just the beginning — interfaces to operate infrastructure require good developer experience. Smith feels that hardware requires an improved buying experience and better life cycle management capabilities. This could be enabled by open source tools like Tinkerbell, a provisioning and workflow engine supported by Linux Foundation.

    Back to the Metal — A Platformer’s Dream?

    All this is not to say the public cloud isn’t valuable – it absolutely is. The cloud has been necessary and has proven resilient enough to support online business and digital life as we know it throughout the pandemic and for years prior. “In 2020 and beyond, most organizations are going to be transforming into a completely cloud-based environment,” said Werner Vogel, CTO, Amazon, during an online AWS summit.

    But, even if most organizations are in the cloud, that doesn’t mean all of their assets will be. Service providers, especially, may cling to hybrid models for more control, to avoid supporting the competition and, perhaps, even to save money. Private data centers could also increase security. In an era where raw computing power is becoming a new asset (quite literally, in the case of cryptocurrency), the server rack is starting to look sexy again.

    “The magic happens when software and hardware work together,” said Smith. But, giving access to physical technology to a generation that has never touched it will require some ingenuity. As Smith says, this could be done by “automating colo” through more usable, standardized interfaces for hardware management.

    “We will see a future in next 10 years where operated software is separated from cloud infrastructure,” Smith said. That’s a bold statement, as such a dramatic change would, in effect, usurp the current cloud provider IaaS market share, altering the distribution and economic model associated with global software.

    While this dream may seem far-fetched, if more platforms decide to cut out the cloud middleman and go it alone, it could materialize.

  • Perforce Adds Synchronization Tool for Cross-Functional Teams

    Perforce Adds Synchronization Tool for Cross-Functional Teams

    Perforce Software has added a graphical tool, dubbed Helix Sync, that enables individuals, such as artists, to take advantage of the version control capabilities provided by its software development life cycle (SDLC) platform.

    Gerhard Krüger, cloud architect and product manager at Perforce, said that as DevOps workflows continue to evolve in the gaming and automotive industries, the need to manage artifacts such as drawings, for example, alongside software artifacts is becoming more pronounced among cross-functional teams.

    Helix Sync gives those end users access to a desktop client that enables any individual to upload artifacts into a system by dragging and dropping them into the Perforce Helix Core SDLC platform.

    Previously, end users that lacked coding skills would need to share files with developers via cloud services such as Dropbox. The Perforce approach removes the inherent friction development teams would otherwise encounter, while at the same time making sure the artifacts being shared are more secure, said Krüger. In addition, end users don’t have to be concerned about file size limitations imposed by file sharing services accessed via the cloud, noted Krüger.

    It’s not clear how many organizations are looking to centralize digital asset management within the context of an application development process, but the fewer places that artifacts reside, the more productive IT teams tend to be. At a time when the number of application development projects within many organizations has accelerated, there’s a lot more interest in reducing the number of steps any developer has to monitor and track.

    Diagrams and other types of artwork are not the only kinds of artifacts that are finding their way into software development processes. Data scientists are building massive artificial intelligence (AI) models that need to be incorporated into application development and deployment processes. The challenge organizations face is the individuals that create many of these types of artifacts lack the programming skills required to share them via version control platforms typically employed by developers.

    With the launch of Helix Sync, IT teams should assume that, going forward, Perforce will be expanding its overall content management capabilities, Krüger added.

    It’s not clear to what degree workflows will converge as application development continues to evolve. Organizations are starting to appreciate just how dependent they are on software. As that awareness increases, it’s only a matter of time before workflows start to converge around the software development process that are employed to drive multiple digital business transformation initiatives.

    With more of the creators of those artifacts working remotely, the security of those software supply chains has also become more critical. Cybercriminals are becoming more adept at compromising the credentials end users create to access a cloud file service. Software development teams are more likely to employ more rigorous forms of authentication.

    Arguably, there’s never been more artifacts to track during the history of application development than there are today. The thing that makes managing all those artifacts even more challenging is, just like every other piece of software, they are also being continuously updated in ways that aren’t easy to discern.

  • Do You Need a Cloud AI Engineer?

    Do You Need a Cloud AI Engineer?

    For all the technological advancements we are witnessing in AI and machine learning, the practical benefits remain elusive in the non-tech business world, frustrating decision-makers as AI investment climbs. For example, over the past several years, many Fortune 500 companies have invested in strong data science teams and AI labs, but still struggle when it comes to producing and scaling their models. Moreover, a recent report by Algorithmia found that, while enterprise budgets for AI and ML are rapidly increasing for 83% of organizations studied, deployment challenges persist.

    These deployment issues often begin when leadership fails to exert enough upfront engineering focus to ensure their proof of concepts (POCs) are “real-world ready.” The challenges are compounded when businesses put these models into action using insufficient, outdated or cobbled-together IT infrastructures. This combination results in POCs that either fall apart under real-world conditions or are rife with inefficiencies. Fortunately, cloud tech today provides the opportunity to overcome these challenges.

    Businesses can enable development, experimentation and scaling of data science and AI solutions with more flexibility and speed than ever through cloud platforms. A design-led AI project that uses the tools available in the cloud can help organizations create business impact and realize ROI much faster.  So while the role of data scientist may have been the ‘sexiest job’ in recent years, we may be seeing a new ‘sexiest job’ title emerging: the cloud AI engineer.

    Why do we need a Cloud AI Engineer?

    Traditionally, a successful AI project in the cloud requires a team with different skills and titles, including data scientists, big data engineers, cloud engineers and full stack developers. This has led businesses to look at ways to merge these specialties into one specific title. Enter the cloud AI engineer who, theoretically, would be able to cover all these duties — including knowledge of and experience with the tools and accelerators that cloud platforms now offer, as well as demonstrated aptitude for fast-paced development in AutoML. These are skills and tasks previously spread out across other areas and roles within the organization.

    What is the Job Description?

    So what would this job actually look like? The cloud AI engineers of the future will focus on the deployment of AI and ML models at scale in the cloud, and on integrating them with existing products and IT systems. Additionally, cloud AI engineers would need knowledge of the different types of machine-learning algorithms; familiarity with frameworks like Tensorflow and PyTorch; hands-on experience with data processing; analysis and feature selection using analytic tools and ETL/ELT frameworks (Apache Spark, Hive, Amazon, Athena, etc.); and model deployment experience on cloud platforms like AWS, Azure or Google Cloud.

    Obviously, tackling all of these would be a huge undertaking for one individual; given the vast workloads on both the cloud and engineering fronts, it isn’t possible to replace these workers and their skills with just a handful of cloud AI engineers. Instead, cloud AI engineers will sit between the two disciplines and the workforces and will serve as a key bridge to easily deploy models and integrate them with enterprise systems and tools for consumption.

    Where are We Going to Find Cloud AI Engineers?

    Given that cloud AI engineers will have a robust level of responsibility, they will quickly become some of the most sought-after team members — but that also means talent for the role will likely be in short supply.

    Additionally, individuals with this broad skill set will not appear overnight — at least not en masse. Therefore, to build the cloud architecture capable of delivering the real-world AI results that businesses need today, tech companies need to find ways to break down the internal divides between data scientists and cloud engineers so that they can cross-train, learn and develop skills in each area. If this is done correctly, not only will tech companies have a more well-rounded workforce, but they will be able to deliver the practical AI success that non-tech businesses are looking for today.

    Despite excitement about AI and its benefits, operational challenges remain. By focusing on the cloud and building up specialists in this space, AI can begin to drive the practical results the business world needs far more quickly.

  • How Low-CodeOps Can Transform DevOps

    How Low-CodeOps Can Transform DevOps

    Over the past year, enterprise adoption of low-code software development platforms surged across the world economy as COVID-19’s economic consequences drove an unprecedented number of digital initiatives. Enterprises are turning to low-code platforms to rapidly build new apps that empower customers, remote workers and external end users conducting business operations or pivoting to new opportunities.

    Accelerating software development, however, only solves half the puzzle of a digital-first approach. Quickly getting solutions into users’ hands requires careful planning to determine how these new applications will function within the organization’s overall software operations strategy. This is often conducted across multiple cloud deployments.

    But the real prize comes when low-code’s underlying principles of automation and abstraction are extended into the DevOps domain of software maintenance and management. The ability to push out a continuous pipeline of software updates with the click of mouse, with streamlined testing and quality assurance, requires a platform that automates myriad, time-consuming tasks associated with building, testing, releasing and maintaining applications in an enterprise-grade production environment. This inevitably leads to the concept of “low-code operations;” or, to coin a phrase, “Low-CodeOps.”

    Indeed, unless the benefits of abstraction and automation — in this case, primarily speed — extend to operations and deployment, the real benefits of low-code development are elusive. A platform that lets you build an app in six days but requires six months to deploy is no solution at all.

    Harnessing the Cloud for Game-Changing Results

    To witness the vital role seamless cloud operations played in business innovation, look no further than biotech giant Moderna and its success in Operation Warp Speed. Moderna used the public cloud to pull together geographically dispersed collaborators, integrate scientific insights and refine its production cycle, enabling the company to deliver its first batch of mRNA vaccine samples a mere 42 days after the COVID-19 virus genome was sequenced. The time-to-value for this solution was definitely warp speed.

    And, it’s safe to assume, expensive. Cloud engineers and DevOps system administrators are highly skilled specialists who roll up their sleeves at 2 a.m. to fix unexpected glitches buried deep in the connected ecosystem of software operations. They figure out how to make the software actually run. Enterprises, no doubt, wish they could hire more of them.

    But the same shortage of skilled IT professionals that fueled today’s demand for low-code software development also impacts DevOps. In this case, the same low-code platform is the solution, empowering a wider cross-functional, collaborative team to reduce operational burdens — in a word, Low-CodeOps.

    Essential Features of Low-CodeOps

    To achieve a frictionless handoff when moving applications and data to the cloud, a production environment leveraging low-code principles will deliver on these key principles of low-code operations:

    Performance monitoring: Daily monitoring and log checks of platform infrastructure are the backbone of modern DevOps operations, ensuring that complex interdependencies are running smoothly. Automated dashboard monitoring can transform hours spent on these repetitive tasks into opportunities for engineering teams to focus on innovation, while still ensuring the health and performance of enterprise software portfolios. The tooling needs to enable automated end-to-end visibility into application workloads and performance characteristics of upstream and downstream services.

    Compliance: Every economic sector is subject to specific government regulations. Software platforms and DevOp teams must keep track of every requirement when integrating new functionality into software upgrades. Banking customers must deploy digital solutions on infrastructure that’s earned ISO/IEC 27001 certification. Healthcare solutions must conform to federally mandated HIPAA requirements. Defense contractors must be FedRAMP certified. Data—the lynchpin of any digital solution—is subject to privacy laws that differ across nations and borders. Imagine having to manually recheck every iteration of your application deployments for compliance. Luckily, low-code operations mean having an automated, system-wide compliance framework in place. This makes short work of service organization (SOC) audits and reporting.

    Security: Cyberattacks that lead to system outages and disruptions are a growing concern in our digitally connected world. Well-resourced cloud giants are not exempt from damaging cyberattacks, such as last year’s SolarWinds hack. Resilience is key. Ongoing security scanning can halt automatic software deployments when suspicious changes are detected. Prevention is always best. Monitoring tools identify vulnerabilities, enabling systems to quickly come back online and help prevent outages that can last for hours or days.

    Infrastructure independence: Widespread enterprise adoption of multi-cloud and hybrid cloud for operational efficiencies has made flexible infrastructure the new standard. Organizations are bypassing single-vendor lock-in to spread workloads across multiple cloud partners. That means DevOps needs streamlined configuration and management tools that can track relationships between resources and keep track of compliance issues. Geopolitical considerations may enter the equation when cloud providers turn out to have close ties with governments antagonistic to other global trading partners. Monitoring instruments that provide observability across the range of vendors consuming enterprise data and applications is mission-critical.

    Resilience: Snafus happen. Platforms can automate continuous domain-level metrics to correlate performance from different sources (including logs, metrics, application tracing and outside penetration testing), speeding up detection and response time. Fast auditing and debugging tools, combined with real-time dashboard monitoring and system-wide alerts, plus an ounce of detection, equals a pound of cure. For agile DevOps teams, reactive firefighting is transformed into resilient firepower.

    Adopting an All-in-One Low-CodeOps Approach

    Low-code’s power to enable frequent iterations of software ideation, creation and deployment may seem contrary to the DevOps mission to minimize risks. However, the same radical abstraction and automation that has made software development faster, higher quality and more accessible to a larger cohort of developers can also reduce the operational burden of landscape management. Every low-code vendor touts the governance features in its platform. But the nuts and bolts of governance require some assembly, including system-wide actionable monitoring, testing alerts and compliance safeguards. Low-CodeOps combines the most efficient, agile, flexible development platform and powerful, streamlined operations tools, infusing both domains with solid guardrails for operational control and predictability. Adopting this approach will greatly increase time-to-value for enterprises, putting innovative digital solutions directly into the hands of end-users with the click of a mouse.

  • Languages and DevOps: To The Cloud!

    Languages and DevOps: To The Cloud!

    Cloud and DevOps are almost a match made in heaven. Cloud started truly gaining steam in the age of DevOps and Agile, and has adapted – or grown up in it – well, depending on your viewpoint. If not for the combined issues of data gravity and data (im)mobility, we might have gone even farther than we did into the cloudy world.

    While the breadth of possible cloud apps means a wide variety of languages is in use, Node rules this roost. Every conceivable language is used in cloud development – because, in the end, they’re just servers – but Node is the go-to language of today. The broad use and appeal of JavaScript make it an obvious choice for enabling full-stack development, and the pool of developers is larger than any other language today. Other languages are used, but not in the numbers that Node is. Python is the challenger, and a surprising number of PHP sites still exist, but forward-looking development aims at Node or Python. Considering the distance from the hardware, there is less call for C in cloud than there is in other areas of development, but it isn’t gone, since interfacing to the OS is also often done in C.

    Targeting cloud is not so much about language as it is DevOps tooling, though. All of the major Git companies have cloud-centric extensions (this is the core of GitOps) that raise the level of “fully automated.” Cloud environments, by their nature, provide APIs for infrastructure, and the Git vendors (and many, many others) have hooked into those APIs to make deployment an integrated part of DevOps at a level of detail that other environments (with the exception of containers) require a lot of work to match.

    The negative to cloud-centric development is lock-in, of course. Creating an entire DevOps toolchain and process that supports vendor X will not work directly with vendor Y. Tools can help with this issue, but the real solution is in our next installment – container development.

    The part of development that arguably benefits the most from cloud-centric development is testing. It is easier to spin up a test environment as-needed and spin it back down when testing is done – no need for a spare set of hardware or a stand-alone VM server; just redirect the DevOps ecosystem and spin it up, then account for data (scrubbing, copying, etc), and you’re off. Codify the steps for data, and you have a re-spinnable environment for test-on-demand.

    The part of cloud that is arguably the weakest is security. Let’s face it, far more of your infrastructure is publicly (or semi-publicly, if running in a VPC) exposed than in a data center. There are far more places to lock down, and a sometimes-bewildering number of options to secure. But the flexibility of pay-as-you-grow makes it an appealing option, and there are tools to help manage all those lockdown points. Just make sure that you’re not the weak point in the shared security model.

    You. Rock.

    Cloud makes a lot of things easier, and Node makes development of any step in the stack easier by using the same underlying language on the server that is used in browsers and in many mobile development platforms. Node “feels” more right for web development, at least because one connection, one call … even if it makes long-running processes require a bit more work.

    Whatever you choose, pay attention to how deeply invested in the cloud vendor’s proprietary interfaces you are, because, like all technical decisions, one day you or your replacement will have to get around those interfaces. And keep making the software the org needs.

  • New Relic Adds Visualization Tool to Observability Platform

    New Relic Adds Visualization Tool to Observability Platform

    New Relic announced today it has added a visualization tool, dubbed New Relic Explorer, to make it simpler for IT professionals to discover the root cause of issues that adversely affect application performance.

    Buddy Brewer, global vice president and field CTO for the Americas, New Relic, said the goal is to make it simpler for IT professionals to navigate and, ultimately, act on, all the metrics collected by the New Relic One observability platform.

    New Relic Explorer includes a New Relic Lookout capability that enables IT teams to drill down into telemetry data gathered from New Relic One, as well as other third-party sources, and a New Relic Navigator capability for determining the health of relationships between services, said Brewer. These capabilities make it possible to more easily identify correlations, abnormal history and traces that would be, for example, indicative of blind spots or unknown relationships between IT services, Brewer said.

    Just as importantly, IT professionals can more easily discover recent changes to an IT environment, which are most likely the cause of any new issue that is adversely affecting the IT environment, Brewer added.

    New Relic Explorer requires no configuration, and will be included as part of the existing New Relic Full-Stack Observability offering to give IT teams a single unified view of their IT environments, said Brewer.

    As IT environments become more complex, the amount of time spent looking for the root cause of an issue that might only take a few minutes to fix has substantially increased. As a result, organizations are allocating a significant amount of time to convene “war rooms” to identify the source of problems; those problems can now be more readily identified using New Relic Explorer.

    In general, Brewer said, New Relic remains committed to opening up the platform to external telemetry sources, including data collected using open source tools, such as Prometheus and OpenTelemetry agent software, both advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

    New Relic, like providers of similar tools, has recently begun repositioning itself as a provider of an observability platform, rather than of application performance management (APM) tools, that provides insights into both applications and the infrastructure on which they depend. That approach promises to provide IT teams with more context any time an issue arises. As part of that shift, New Relic is making it clear that while it views its agent source as a richer source of telemetry data, its platform can consume relevant data wherever it can be found. New Relic will also remind customers that its agent software, and the other data collection tools it provides, are simpler to install and update.

    The tradeoff, of course, is cost. While open source software itself is free, the total cost of implementing and managing that open source software can be substantial. Regardless of approach, however, the days when IT teams only applied application monitoring tools to their most mission-critical applications because of cost concerns are coming to an end. It has become impossible to manage a modern IT environment made up of both monolithic and microservices-based applications without such capabilities.

  • Overcoming Cloud Asset Management Challenges

    Overcoming Cloud Asset Management Challenges

    Twenty years ago, no one in IT could have predicted the monumental role that cloud computing would play in our everyday lives. To play off the words of Back to the Future‘s Doc Brown: “On-premises? Where we’re going, we don’t need on-premises.” As technology continues to evolve, though, security teams face greater challenges.

    Infrastructure is no longer server rooms and boxes; it is dynamic, changing constantly to support fluctuations in demand. And moving to the cloud introduces new third parties into the digital mix. Although AWS, Google, and other cloud providers have a lot at stake when it comes to protecting customer data, security responsibility is never completely out of an organization’s hands. Compliance considerations are yet another complicating factor. In many cases, regulations around data access, privacy and residence were created for an on-premises world.

    Looking to the future, companies want to maximize their investments in the cloud, while better addressing these security challenges. However, the rapidly changing nature of the cloud makes it difficult for security teams to fully understand the scope of assets they are responsible for at any given point in time, which is an absolute necessity in order for companies to truly be secure. After all, how can a company make sure it has no gaps in its cloud security if it can’t account for all cloud assets – especially when working with multiple cloud providers?

    Security teams need to inventory their entire cloud infrastructure, understand what controls are in place and find ways to detect and mitigate any vulnerabilities or misconfigurations in a timely manner.

    Understanding Cloud Workloads

    When moving assets to the cloud, it can be incredibly difficult to try to inventory devices with dynamic IP addresses, which constantly change, compared with more static devices. The mass adoption of containers and microservices, some of which exist for just seconds before disappearing, make dynamic systems even harder to track.

    One of the most important improvements that have come out of cloud growth is that everything has an API, which can be a massive advantage when inventorying assets. Because each cloud provider is self-contained, finding out when a new bucket or instance is created is certainly possible. Organizations that have advanced development capabilities can write and maintain their own applications to identify every new cloud instance for each provider – but doing this for multiple cloud providers and correlating cloud asset inventories with other security control data becomes a major investment of resources. The ability to access all resources in the cloud makes asset management a more achievable goal.

    Security Controls

    It is essential for organizations to carefully manage their assets and understand the security controls in place to know exactly what they cover. By categorizing their resources, companies not only better understand what they have, but can make informed decisions about exactly what additional security measures need to be taken. For example, vulnerability scanners may not be scanning critical workloads – or perhaps dedicated cloud workload protection platforms need to be deployed for certain cloud assets. It can be incredibly difficult for security systems to keep up; since cloud assets can be created so quickly, they need security systems tailored specifically to keeping them safe.

    A security tool can only secure devices that it knows exist. Once an organization understands the assets it has, it can expand the coverage of any existing tools to devices that were previously unknown. When that coverage is fully adopted, asset management can help the organization find gaps in its coverage to identify areas for additional protection and the right tools to secure them.

    Addressing Vulnerabilities and Misconfigurations

    Once an organization establishes a comprehensive asset inventory and visibility, the next step is to address vulnerabilities, gaps in coverage or misconfigurations that are found. With the ability to spin cloud instances up or down at will, it is inevitable that instances may be forgotten and inadvertantly left unprotected. Since cybercriminals automatically scan public cloud infrastructure to exploit these types of vulnerabilities, public-facing cloud workloads are especially at risk.

    Similarly, finding and addressing misconfigurations in cloud workloads becomes more complex. With the highly configurable nature of the cloud, mistakes happen often, and without proper security controls in place to detect these misconfigurations, attackers can easily access and steal data. Organizations must implement a process to continuously detect cloud workload misconfigurations.

    A great place to start is the Center for Internet Security (CIS) Benchmarks, which provides objective security guidelines. By comparing data from each cloud provider with the rules in the CIS Benchmarks, security teams will be able to identify assets that don’t adhere to best practices.

    The key to maintaining security in a modern cloud environment is to implement continuous discovery and interrogation, which requires automation. This includes the ability to create tailored alerts when certain conditions are met, and automatically deploy and change security controls as needed. Teams should set restrictive access controls by default so that non-approved users don’t have access to sensitive data. Any time a cloud workload deviates from policy, there should be a plan in place to automate the corrective action.

    Computing technologies continue to evolve at a staggering pace. The computing environment 20 years from now won’t resemble even the most far-fetched, futuristic ideas today. The evolution of cloud adoption from justified skepticism to ubiquity taught us an important lesson: change is constant. It is incumbent upon technology and security professionals to  constantly challenge the expectations of security solution coverage and adherence to controls to keep data and systems protected.

  • Morpheus Data Adds Midmarket Edition of Hybrid Cloud Platform

    Morpheus Data Adds Midmarket Edition of Hybrid Cloud Platform

    Morpheus Data announced today it is adding a more turnkey edition of its hybrid cloud platform aimed at midmarket IT organizations.

    Priced starting at $16,000, Morpheus Essentials can be deployed on VMware, Nutanix, Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP), with support for Kubernetes planned.

    At the same time, Morpheus Data is updating its core platform to add support for a Plug-in Framework that provides integrations with nearly 100 cloud services without requiring DevOps teams to write code. The company is also adding support for a shopping cart capability through which third-party applications can be automatically deployed as a service.

    Finally, Morpheus Data is adding scanning tools based on the security content automation protocol (SCAP) to make it easier to embrace best DevSecOps practices.

    Brad Parks, chief marketing officer for Morpheus Data, said the goal is to reduce the level of friction IT organizations encounter when trying to centralize the management of public clouds and on-premises IT environments. With more organizations than ever now managing two or more clouds alongside an on-premises IT environment, the need to unify the management of those platforms has become more pressing, he noted.

    The current state of the economy requires IT organizations to reduce the number of management consoles they need to master for each platform, which Parks noted reduces the cost of IT labor because organizations no longer need to designate a specialist to manage each platform employed. The Morpheus platform also enables IT organizations to set up guardrails that enable DevOps teams to self-service their own requirements regardless of platform within the context of policies defined by IT operations teams, he added.

    Of course, the Morpheus Essentials edition of the hybrid cloud platform might also appeal to smaller units within larger IT organizations that need to manage a range of platforms that as yet may not be as widely employed as the platform the rest of the enterprise has standardized on.

    It’s not clear to what degree IT organizations may finally be moving to centralize the management of IT just yet, but the rise of edge computing may finally force the issue at a time when most IT teams continue to work from home to help combat the spread of the COVID-19 pandemic.

    Nevertheless, IT teams are prone to be protective of their individual fiefdoms. As such, convincing them to give up a specific platform console in favor of a platform that can be applied more widely can be a challenge. There always will be a trade-off between the capabilities available in a management console that was created for a specific platform and a management console designed for multiple platforms. The issue IT leaders will need to determine is to what degree a missing capability might have a meaningful impact on the productivity of the IT team.

    Regardless of the platform selected, the one thing that is clear is as IT becomes more complex to manage the current status quo is not likely to hold.

  • Achieve Cloud Resilience Through Systematic (and Chaotic) Testing

    Achieve Cloud Resilience Through Systematic (and Chaotic) Testing

    Constantly testing the cloud in systematic and chaotic ways will help companies avoid cloud failures in a time when downtime means disconnect

    Professionals fortunate enough to shelter in place and work from home can thank cloud for their ability to shift over so seamlessly during the COVID-19 pandemic.

    Imagine a lockdown without the cloud. Availability and uptime of grocery order systems would depend on a company’s on-prem data centers. Streaming services would stutter and stall during peak hours (after dinnertime and other high-demand times. Critical personal and professional interactions would be limited to voice calls instead of rich collaboration apps, video conferencing or dynamic social media. Many companies would simply just be closed to business, unable to respond to market changes and consumers.

    Now imagine a COVID-19-induced work-from-home scenario with downtime in the cloud. Teams working remotely would fall apart. Deliveries would be scrambled and lost. More importantly, emergency services would see bigger surges with fewer tools to manage them. Medical research teams around the globe currently sharing coronavirus research and data would lose contact with each other, delaying and slowing efforts to treat and cure the COVID-19 virus.

    It may seem that the cloud was built just in time to help with our current predicament. But the concept and foundational systems of cloud computing go back more than 50 years. Popular, practical cloud applications developed more rapidly in the past 20 years, starting with the early iterations of Salesforce.com and more recently with web-based enterprise applications such as Google’s G Suite and Microsoft’s Office 365. It’s the simplicity of these relatively newer tools that have led to their broad adoption. But this surface layer masks a mind-bogglingly complex undergirding that must be fully understood and tested to be maintained.

    Clouds are strained right now. IBM endured a cloud outage of roughly two hours on June 9. Network monitoring company ThousandEyes told tech news site Fierce Telecom that the global nature of the outage suggested a control-plane issue rather than a physical failure such as a fiber cut or router failure. Microsoft’s Azure Cloud Data Center capacity in Europe has shown signs of stress as companies shift to remote work and usage of its communication and collaboration platforms, including Teams balloons. To relieve that stress, Microsoft restricted access to free and trial accounts. Google Cloud’s Kubernetes platform and networking services on parts of the U.S. East Coast went dark for a few hours on June 29.

    To avoid downtime due to cloud failure, companies must build resilience into their cloud structure by testing it in continuous and chaotic ways.

    Conventional testing fundamentally ensures that key applications have been migrated or set up in the cloud and are working properly. This is a great and proven way to ensure that cloud systems meet design considerations and do not change based on application performance. However, conventional testing does not probe for unexpected situations. To do that, advanced operations turn to chaos testing, a technique pioneered by Netflix during its own migration to the cloud starting in 2011. Chaos testing creates turbulent situations that will bring points of failure to light and influence design. Modern cloud systems bring hardware and software together in such complex and fluid ways that standard testing will never suffice. By engaging in systematic and chaotic testing, companies can develop greater resilience in the cloud and through their entire technology systems.

    To achieve resilience, IT must find vulnerabilities not revealed in normal “happy path” testing scenarios. Seeking resilience provides a glimpse into a systems’ reliability and recoverability by executing a carefully planned set of disasters. Such a disaster sequence could include:

    1. Pulling down the network connection for 10 seconds.
    2. Taking a service or server offline.
    3. Choking middleware and watching for anomalies.

    Enterprises just embarking on their migration to cloud must first study and choose a service model that fits best. Firms looking to migrate a whole workload to the cloud should choose the infrastructure-as-a-service (IaaS) option, which allow teams to rapidly orchestrate their test environments on the cloud and quickly set up systems for storage, backup and recovery.

    Organizations already in the cloud or partly migrated must take time to understand their cloud service models. This could prompt the question: Is this model right for my organization in the years ahead?

    While operating in the cloud, these companies can start planning testing scenarios to gauge their systems’ resiliency. In doing so, companies should set an objective and time window for running the tests. Then, the results of these tests help inform the requirement design phase of their cloud setup.

    With all systems and applications in a virtual cloud context, future digital transformations will become more fluid. Properly tested clouds also handle demand spikes more readily and will handle the viral adoption of an application or a rapid location switch or expansion of workforces.

    To become resilient, companies must create resilient IT systems. These systems will rely partly or wholly on cloud infrastructure. Cloud infrastructure grows more resilient through constant, systematic, and chaotic testing. Consistent, creative testing has its own value that allows businesses themselves to become more flexible and resilient enterprises.