Category: DevOps in the Cloud

  • TikTok Shuns Russia | War on Patent Trolls | Chrome is ‘Faster than Safari’

    TikTok Shuns Russia | War on Patent Trolls | Chrome is ‘Faster than Safari’

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: ByteDance restricts TikTok in Russia, Unified Patents escalates the fight against trolls, and Google Chrome beats the magic 300.

    1. Not for your For You Page

    First up this week: Russian TikTok users won’t be able to view or upload new content. For users in Russia, TikTok has frozen its catalog of cringe.

    Analysis: Emotional damage

    Putin’s vague new “fake news” law is concentrating minds in Beijing’s ByteDance. Is your organization exposed too? To protect its employees—and perhaps its users, too—it’s hitting the Safe Mode button.

    Dan Milmo: TikTok restricts service in Russia

    Chinese-owned TikTok said it would block livestreaming and uploading of new content in Russia after the Kremlin criminalised the spreading of what it deems to be fake news about its invasion of Ukraine. … The BBC, CNN and other global media outlets have temporarily suspended reporting in Russia to protect their journalists.
    …
    TikTok spokesperson Hilary McQuaide said the app in Russia now appears in “view-only” mode and won’t let people post or see new videos or livestreams. They can still see older videos, but not if they came from outside the country.
    …
    She said, “The safety of employees is our top priority,” … adding that the video-sharing service—part of China-based tech company ByteDance—did not want to put either its Russian employees or users at risk of severe criminal penalties.


    With more on that head-scratching law, here’s Aimee Chanthadavong:

    Russian President Vladimir Putin signed a new law on Friday that bans what the country calls “fake” news about the military. This law will target any statements referring to the invasion of Ukraine as an “invasion”, any attempt to discredit the armed forces, or calls for sanctions on Russia. Those found to be spreading so-called fake news could face up to 15 years in prison.
    …
    TikTok’s in-app messaging service will not be affected. … “We will continue to evaluate the evolving circumstances in Russia to determine when we might fully resume our services with safety as our top priority,” TikTok added.


    And Scott Nover thinks about the effects on Russian citizens:

    Russia’s fake news law is a severe step for a country whose government is already antagonistic to … a free press. … The country has blocked Facebook, Twitter, and YouTube proactively, but TikTok beat Russia to the punch. The result is the same, however: The people of Russia … will be locked out from another window into the real-life consequences of Putin’s war.


    2. Patent Trolls Still Attacking

    “Patent assertion entities,” also known as “non-practicing entities,” are organizations that don’t produce anything, but simply acquire and hoard patents—later asserting them against unsuspecting organizations. The aim is to extort money from those they claim are infringing.

    The problem? Many of those patent claims are as weak as a sickly kitten.

    Analysis: PAEs aka NPEs are NBG—SNAFU

    You might think you’re safe, but trolls also go after the users of the disputed technology. Examples include podcasting, JPEG images, order-confirmation emails, geo-locating a car and even caching data.

    Steven Vaughan-Nichols: Open Source Zone grinds away at patent trolls

    Patent trolls, aka Patent Assertion Entities (PAEs), have plagued … software for ages. … The attacks keep mounting up. The reason is simple: It’s profitable.
    …
    [But] Unified Patents, an international organization of over 200 businesses … brings the fight to the trolls. It deters patent trolls from attacking its members by making it too expensive for the troll to win. … With United Patents’ high success rate in knocking out bad patents, slowly but surely the patent trolls are being driven back.
    …
    For example, an Accelerated Memory Tech patent 6,513,062, was used by the troll IP Investments Group to claim … Redis, which manages cache resources on the cloud, violated the patent. [The troll] went after Hulu, Citrix Systems, Barracuda Networks, Kemp Technologies, and F5 Networks for their use of Redis software. IP Investments Group gave up rather than fighting it out. Everyone who uses Redis wins.


    Ban software patents? Beware of throwing out the baby with that bathwater, thinks WierdUncle:

    Patents themselves are a good idea: … Inventive people should be rewarded for their contributions to the economy.
    …
    [But] patent trolls are parasites who contribute nothing to the prosperity of citizens. … The patent troll business plan is unfortunately quite viable. You don’t invent anything, or fund new developments. You have sufficient funds to clobber anybody who challenges you, by having better lawyers.


    The underlying issue is weak patents. Here’s nzkbuk:

    Start suing the patent office for damages against wrongly issued patients. It would then be in their best interest to set up this sort of thing as an alternative where the patient can be investigated first.


    3. Google Gloats on Chrome Mac Perf

    Google Chrome on macOS boasts a better benchmark score than Safari on an M1 MacBook Pro. Hilariously, this is using Apple’s own Speedometer benchmark tool.

    Analysis: Benchmarks aren’t the be-all and end-all

    Great PR, and popcorn-worthy Cupertino trolling. But aren’t there better optimizations Google could be making?

    Frederic Lardinois: Chrome on macOS is now faster than Safari

    Version 99 of Chrome on macOS manages to score 300 points on the Speedometer benchmark, which was originally developed by Apple’s WebKit team. This, Google points out, is the fastest performance of any browser.
    …
    It’s been a while since competition in the browser market focused on speed. … When a new chip comes along, though, there’s always room for optimization. Originally, Chrome on Apple’s M1 chips had passable performance, but … Chrome now runs 43% faster on them.
    …
    Speedometer 2.0 tests for responsiveness, which makes it a good proxy for user experience. … It doesn’t take much to make software feel more responsive, so the 43% on M1 Macs will surely make you feel more productive.


    How? Try not to gloat, Max Christoff:

    Building on many performance changes over the last year, we enabled ThinLTO in M99, a build optimization technique that inlines speed-critical parts of the code base, even when they span multiple files or libraries. … Two of the other recent major contributors to Chrome’s speed are the V8 Sparkplug compiler and short builtin calls. Sparkplug is a new mid-tier JavaScript compiler. … Short builtin calls are used by the V8 JavaScript engine to optimize the placement of generated code inside the device’s memory [which] boosts performance by avoiding indirect jumps when calling functions.
    …
    We know that benchmarks are just one of many ways of measuring the speed of a browser. [But] combined with recent graphics optimizations (namely, pass-through decoder and out-of-process rasterization) … Chrome is now 43% faster than … 17 months ago.


    Benchmarks/schmenchmarks, thinks codedokode:

    Browser developers are optimizing the wrong thing. … Optimizing for speed usually causes increased memory consumption, and this increases the chance of invoking swapping. If the system starts swapping, it becomes orders of magnitude slower.
    …
    If the browser could use [half the] memory while using twice amount of CPU time, that would be perfect. Just think how many laptops with 2 or 4 GB of RAM would become usable again.


    The Moral of the Story: Good words shall gain you honor, but good deeds shall gain you friends.


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Rostislav Artov (via Unsplash; leveled and cropped)

  • Pulumi Adds Business Critical Edition to Infrastructure Management Platform

    Pulumi Adds Business Critical Edition to Infrastructure Management Platform

    Pulumi today added a Business Critical edition of its Cloud Engineering Platform that provides large enterprises with additional security and compliance features, premium 24×7 support, training, professional services and a self-hosting option.

    In addition, the company announced that Pulumi Enterprise and Business Critical editions are now available via the online marketplace run by Amazon Web Services (AWS), with future availability on other marketplaces planned.

    The Cloud Engineering Platform from Pulumi enables DevOps teams to use Pulumi Packages to create reusable components for automating IT infrastructure provisioning. Those can be embedded within workflows and applications using an application programming interface (API) that Pulumi has exposed. IT teams can define a Pulumi Package in the programing language of their choice.

    Aaron Kao, vice president of marketing for Pulumi, said the Cloud Engineering Platform from Pulumi provides an alternative to managing infrastructure-as-code (IaC) that can be centrally managed more easily than open source tools like Terraform.

    Pulumi reported that adoption has accelerated across enterprises around the world with more than one million downloads per month. The company claimed it has seen 350% year-over-year growth of its enterprise customers, such as Mercedes-Benz, in the last 12 months.

    IT organizations in general are looking to bring some order to chaotic provisioning processes to avoid misconfigurations that often result in, for example, a developer leaving a port open; that open port leaves a vulnerability through which data can be exfiltrated.

    As organizations focus more on software supply chains in the wake of recent high-profile breaches, it’s only a matter of time before more questions arise about how cloud infrastructure is being provisioned. Much of the concerns organizations already have about cloud security don’t stem from the platforms themselves. Rather, it’s the processes employed to provision infrastructure under a shared cloud security responsibility model that results in so many vulnerabilities. Developers often assume the cloud service provider is securing configurations, only to discover later that it was their own responsibility to validate those configurations. Security teams, meanwhile, can’t keep pace with the rate at which cloud infrastructure resources are being provisioned.

    Centralizing infrastructure management is especially important as the number of cloud platforms IT organizations manage continues to expand and the rate at which applications are built and deployed shows no sign of slowing, noted Kao.

    It’s not clear whether development or IT operations teams will ultimately wind up managing the provisioning of infrastructure. Pulumi is making a case for a platform that enables those teams to more closely collaborate within the context of a set of policies and DevSecOps best practices that the IT organization defines.

    It may be a while before the bulk of enterprise IT organizations are able to exercise the political will to regain control over IaC provisioning. However, in the absence of guardrails that allow IT organizations to make sure infrastructure is properly configured, it’s only a matter of time before tougher questions are asked about how software supply chains are managed.

  • Ukraine Asks for DNS Censorship | Ukraine Snapchat Staff Danger | #BoycottKaspersky?

    Ukraine Asks for DNS Censorship | Ukraine Snapchat Staff Danger | #BoycottKaspersky?

    Welcome to Ukraine Week here at The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Censoring the Russian internet, Snap fears for hundreds of Ukrainian employees, and Eugene Kaspersky acts like a ****.

    1. ICANN, but IWONT

    First up this week: Ukraine has asked ICANN to drop Russia from the DNS. Andrii Nabok, the Ukrainian representative of ICANN’s Governmental Advisory Committee argues a DNS blockage would “help users seek for reliable information in alternative domain zones, preventing propaganda and disinformation.”

    Given today’s confirmation that Muscovite K12 students had been arrested for laying flowers at the Ukrainian embassy, this goal seems all the more laudable. But frankly, a moment’s thought says it’s a bad idea.

    Analysis: “The net interprets censorship as damage and routes around it”

    John Gilmore was right. Such a move would inevitably fail. And there’s a real risk of undesirable, unintended consequences.

    Kat Bouza and Noah Shachtman: Ukraine Pushes to Unplug Russia From the Internet

    Ukraine’s request to the Internet Corporation for Assigned Names and Numbers (ICANN) seeks to revoke domains issued in Russia and shut down primary Domain Name System (DNS) servers in the country. [It] would send a strong message to a regime pumping out digital propaganda.
    …
    The DNS root zone is a crucial element of the overall functionality of the internet, responsible for handling queries to top-level domains — such as .com, and country-specific domains like Russia’s .ru. Removing Russia’s access to this cluster of servers would prevent Russian internet-service providers from communicating.
    …
    But … the unprecedented request has the potential to do more harm than good. … Representatives for ICANN … declined to comment.


    But the request is pretty naïve, thinks this Anonymous Coward:

    All they would have to do is get the ISPs to add a zone to their DNS that says “ru. IN NS x.x.x.x” and then for all their users, any requests for a .ru domain would be directed to x.x.x.x

    OK, the rest of the world would miss out, but I doubt that they would care.


    Is there a better way? ArmoredDragon breathes fire:

    A better way … is to ask western certificate authorities to revoke all [Russian] certificates. Then ask the major OS and browser vendors to remove any CAs that don’t comply.

    That would really **** with them because there’s nothing [Russia] can do about that. And it would even **** with Russia’s ability to do business with Chinese companies and Chinese customers.


    2. Fear for 300 Ukraine Employees at Snap

    Snap, Inc.—formerly Snapchat—owns the Ukrainian company that created the technology used in the real-time video shenanigans behind “I’m not a cat.” It has hundreds of employees in Kyiv and Odesa.

    Analysis: Solidarity doesn’t Stop Wars, but Sanctions Might

    This very human DevOps story is but a footnote to the wider picture of tech companies acting to echo Western governments’ sanctions. It’ll cause us a little pain, but that’s nothing compared to the suffering felt by Ukrainians. And it’ll be worthwhile if it shortens the war.

    J. Clara Chan: Three hundred Snap employees are from Ukraine

    In a public note, … Snap — the parent company of Snapchat — said … that 300 of Snap’s “most creative and talented team members” are from Ukraine, … the birthplace of Looksery, the augmented reality platform that Snap acquired in 2015. … Snap said it has pledged over $15 million in humanitarian aid to support Ukraine. … The company is also providing emergency assistance to employees who need help safely relocating.
    …
    “We stand in solidarity with our Ukrainian team members and the people of Ukraine. … This is a devastating conflict with far-reaching consequences. … It is a direct threat to many of our team members and their families.
    …
    “Over many years working with our Ukrainian colleagues and friends, we have gotten to know the inventiveness, strength, and resilience of the Ukrainian people. … We will continue to work tirelessly to help our Ukrainian team members and their families, support our Snapchat community, and determine how we can help make positive contributions to the immense humanitarian efforts underway.”


    It’s bang on trend, reports Corinne Reichert:

    Snapchat has followed suit after Facebook, Twitter and YouTube began pausing ads on Friday, saying it has now stopped all advertising running in Russia, Ukraine and Belarus following the Russian invasion of Ukraine. … The Snapchat app remains live in Ukraine, Russia and Belarus, [but] Snap is monitoring the platform for misinformation or other misuse.
    …
    Apple has also halted sales of its products in Russia, as well as online transactions, Apple Pay and some Apple Maps features. Google [is] temporarily disabling some live Google Maps features, adding an SOS alert to Search and blocking Russian state-controlled media. It said Google Pay “may become unavailable.”


    But don’t hang up on Dade “+++ATH” Hayes: [ask your parents]

    In terms of any financial sacrifice from the foregone advertising opportunities, it isn’t clear that all that much is at stake for Snap. … While the company’s stance on the Russia-Ukraine situation clear and emphatic, it is also an easier one for for Snap to take than for many of its tech rivals.


    3. Yevgeny Valentinovich ‘Eugene’ Kaspersky has Chosen the Side of the Oppressor

    The figurehead eponym of AO Kaspersky Lab is being publicly shamed for comments he made about the war in Ukraine. In stark contrast to Snap’s statement, he is accused of overt neutrality, minimizing the war’s severity—and even of shoehorning in some marketing.

    Analysis: #BoycottKaspersky

    Desmond Tutu was right. But, while it’s tempting to “cancel” Eugene, dial down the emotion and think instead about your security posture. If you use Kaspersky products internally, what risks are you exposing your organization to? How might the Russian government exert pressure on the company to compromise your network?

    James Coker: Eugene Kaspersky’s Statement Provokes Controversy

    Cybersecurity industry veteran Eugene Kaspersky has provoked a strong reaction from leading figures in the sector. … Kaspersky, CEO of the Russian-headquartered IT security vendor of the same name, broke his silence on the conflict:
    …
    “We welcome the start of negotiations to resolve the current situation in Ukraine and hope that they will lead to a cessation of hostilities and a compromise. We believe that peaceful dialogue is the only possible instrument for resolving conflicts. War isn’t good for anyone. … The main thing we can do in this situation is provide uninterrupted functioning of our products and services.”
    …
    His description of the conflict as a “situation” and apparent attempt to advertise his firm led to a number of furious responses. … Following Kaspersky’s tweet, the hashtag #BoycottKaspersky appeared.


    With a balanced view, it’s Nick Farrell:

    Kaspersky sits on the fence … in Russia it is not a good idea to have a view. [But] whoever is advising Kaspersky on PR might need to have a rethink.
    …
    After all a compromise is [not] always possible when one side is firing missiles into residential areas. If he applied the same premise with ransomware, he would be suggesting, … “It is better that you talk to the people who are holding your servers hostage.” … How much is Kaspersky, the company, influenced by the Russian government?


    Does your shop use Kaspersky? Nick Lange cuts to the chase:

    I would like to remind all readers that, in case of war, … software with access to companies and the capacity to be updated worldwide in matter of hours at the same time is a high class target to get forced to cooperate by a autocratic government.


    The Moral of the Story: If an elephant has its foot on the tail of a mouse and you say that you are neutral, the mouse will not appreciate your neutrality.


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Brandon Morales (via Unsplash; leveled and cropped)

  • Multi-Cloud Computing is a Major IT Headache

    Multi-Cloud Computing is a Major IT Headache

    A CloudBolt Software survey of 500 senior IT, DevOps, security and finance leaders found 79% are struggling under the weight of managing multiple cloud computing environments.

    The survey from CloudBolt Software, a provider of a cloud management platform, found specifically that more than three-quarters of respondents (78%) said they have too many cloud tools throughout their enterprise, and 80% struggled to achieve comprehensive visibility into cloud usage and spending. A total of 80% also noted that their current approach to cloud computing created new security vulnerabilities.

    A full 88% said they need a “manager of managers” that would enable them to unify the various silos that have multiplied across their IT environment.

    Nevertheless, 78% of respondents said that moving to the cloud enabled them to achieve cost savings compared to running applications in an on-premises IT environment.

    CloudBolt Software CEO Jeff Kukowski said the issue is not so much that IT organizations regret shifting workloads to the cloud; instead, the issue is finding a way to manage multiple clouds, each with their own set of tools and frameworks that need to be mastered.

    It’s not clear whether organizations are deliberately employing multiple clouds or if, because of simple inertia, they have found themselves managing multiple cloud platforms because of decisions made by various development teams. Some IT organizations, for example, employ multiple clouds because they are concerned about either becoming locked into a specific cloud computing service or whether an outage might take all their applications offline at the same time. Others are simply trying to take advantage of services that are better provided by one vendor than another.

    Regardless of how IT organizations found themselves managing multiple clouds, the total cost of IT rises as each new platform is added to an IT environment. CloudBolt Software is making a case for an IT framework that provides a layer of abstraction through which the management of multiple clouds and on-premises IT environments can be unified. It is more a question of time and degree to which IT organizations will eventually consolidate the management of disparate IT environments under a single control plane that provides the foundation for true hybrid cloud computing, said Kukowski.

    There are, of course, a few organizations that have standardized on a single cloud computing platform. The degree to which those organizations can maintain that standard will naturally vary as, for example, new workloads that may be optimized for a specific cloud environment are built or as companies acquire other organizations that are running workloads on other cloud platforms. In many of those cases, organizations discover that the cloud services invoked expose a range of proprietary application programming interfaces (APIs) and disparate virtual machines that make migrating workloads a major challenge.

    Like it or not, most organizations will be managing multiple IT environments for the foreseeable future. The only thing that is uncertain is the volume of workloads that might be running on any one of those platforms at any given time.

  • Tricentis Expands Scope of Cloud-Based Testing Tools

    Tricentis Expands Scope of Cloud-Based Testing Tools

    Tricentis this week extended a suite of cloud-based testing tools that promise to make it simpler to both develop cloud-native and mobile applications and migrate existing applications to the cloud.

    New capabilities added to the portfolio include integrations for cloud-based planning tools and a wider range of testing capabilities for mobile applications. DevOps teams can now, for example, deploy Tricentis qTest platform for managing the testing process within a Kubernetes cluster. Tricentis has also made it simpler to configure and update its Tosca suite of application testing tools.

    In addition, Tricentis added additional capabilities for testing SAP applications running in the cloud that previously were deployed in an on-premises IT environment.

    Martin Klaus, vice president of product marketing for Tricentis, said the goal is to make it simpler for DevOps teams to integrate continuous testing for various types of applications within their DevOps workflows. DevOps teams have the option of invoking the Tricentis suite of testing tools via a software-as-a-service (SaaS) platform or deploying them on a cloud platform themselves using templates provided by Tricentis.

    While developers are clearly getting more involved in testing, Klaus said it’s critical for testing capabilities to be integrated within a DevOps pipeline. Each developer is typically only working on a component of a larger application. Unless testing is conducted on an end-to-end basis, an organization won’t be able to determine the real quality of the application experience before deploying software in a production environment, he noted.

    As a result, the decision about what tools to use as part of a continuous testing process is now being made by DevOps team leaders rather than individual developers, added Klaus.

    Ultimately, the goal is to automate as much of the continuous testing process as possible. Achieving that goal will require increased reliance on artificial intelligence (AI) technologies, though to varying degrees, said Klaus. Those capabilities, however, are not likely to eliminate the need for dedicated testing professionals; instead, AI will enable those teams to more efficiently test increasingly complex application environments, he added.

    In fact, it’s becoming practically impossible for testers to manually inspect every element of an application without the help of, for example, algorithms that apply computer vision to analyze a user interface, noted Klaus. There will always be higher-level tasks that require a human, but AI technologies will play a significant role in enabling testing at scale as organizations start to build more applications, he added.

    In the meantime, it’s clear that there’s a lot more riding on testing as organizations continue to launch digital business transformation initiatives. In many cases, organizations only get one chance to convince end users that a new application being rolled out is better than the processes they previously employed. As such, the need to streamline testing within the context of a DevOps workflow has become critical—there is little tolerance for bottlenecks that slow down the rate at which applications now need to be built and deployed.

  • Akamai: Buying Linode | Firefox: Not OK | Gone: Google Vaccine Mandate

    Akamai: Buying Linode | Firefox: Not OK | Gone: Google Vaccine Mandate

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Linode gets bought by Akamai, Firefox market share is “measly,” and Google brings staff back to the office.

    1. Akamai + Aker = ‘Synergy’

    First up this week: Why is Akamai buying Linode? Whatever the reason, it’s a big payday for its solitary shareholder: Not far off a billion dollars.

    Analysis: There goes the neighborhood?

    The 100 lb gorilla of edge computing and CDNs is promising not to mess with Linode’s winning open source cloud formula: No change, steady as she goes, etcetera. But how many times have we heard that before?

    Here’s local scribbler Paige Gross: Linode’s $900M acquisition by Akamai is a ‘game changer’

    A household name in the Philly tech scene … CEO Christopher Aker founded the company in 2003, and it’s been bootstrapped ever since, growing to about 250 employees. … Aker has owned 100% of Linode since he founded it.
    …
    Aker said the deal brings the company closer to solving evolving challenges “as cloud services become all-encompassing, including compute, storage, security and delivery from core to edge. … We’ve been talking about ‘alternative cloud’ — alternative to the big guy — and now we’ve sort of validated ourself in this market.”
    …
    The Old City company maintains “well over a million accounts” but has anywhere around 150,000 active users of its platform at any particular time. Linode’s HQ, the bank building at Third and Arch Streets, remains. … For clients and Linode employees, there won’t be too much noticeable change [Linode] says.


    Why does Akamai want Linode? Jonathan Greig asked the CEO:

    Akamai CEO Tom Leighton [explained] that Linode has great customer support and is already in 11 locations, which Akamai is going to “dramatically” expand. … Leighton also noted the September 2021 acquisition of Israel-based Guardicore, a cybersecurity company that offers a micro-segmentation solution to reduce the potential attack surface of corporate networks, secure applications, and meet compliance standards.
    …
    According to Leighton, the company is expecting the cloud compute category — which includes edge applications, its net storage business, and Linode — to reach “well over half a billion dollars in 2023. … We were pioneers in edge computing and now we’re taking a big step forward in cloud computing with Linode.”


    But here’s a worried-sounding zoid.com:

    Well good for them but I hope [Akamai] don’t screw it up. Linode is a great hosting company.


    2. Firefox isn’t OK

    Last week, a journalist innocently asked, “Is Firefox OK?” And people lost their minds.

    Analysis: No, not OK—it’s a big problem for DevOps and the web.

    We need Firefox and Gecko. A Chromium monoculture is bad for the web and bad for DevOps. (Before you ask: No, the existence of WebKit doesn’t change things, thanks to Apple’s ridiculous policies). Much as I tried to say something nice about Firefox last month, its market share is, frankly, pathetic.

    Matt Burgess: Is Firefox OK?

    In the two decades since Firefox launched from the shadows of Netscape … the browser has slid to less than 4 percent of the market—on mobile it’s a measly half a percent. … Its fate also has larger implications for the web as a whole.
    …
    Each year Google pays Mozilla hundreds of millions of dollars in royalties. … In its 2020 financial results … Mozilla listed its total revenue as $496 million. … The Google-Mozilla deal was last renewed in 2020 and is expected to expire in 2023. … Mozilla and Firefox acknowledge that for its long-term future it needs to diversify the ways it makes money.
    …
    Firefox still matters: … The browser market is dominated by Google’s Chromium codebase and its underlying browser engine, Blink. … Microsoft’s Edge Browser, Brave, Vivaldi, and Opera all use adapted versions of Chromium. Apple [has] its WebKit browser engine [but] other than that, Firefox’s Gecko browser engine is the only alternative.


    Firefox, how do we love thee? Let not_count_zero count the ways:

    I still use Firefox because:
    a) I remember Internet Explorer and the standards wars. …
    b) I don’t trust Google. …
    c) Most sites work well.
    …
    I do have questions though. … They’re currently getting around a half a billion‽ What are they doing with it? … This seems really off—really, really off.


    But heed a deeply worried Thom Holwerda:

    The decline and potential demise of Firefox is a massive problem that everybody seems to be kind of tiptoeing around—too afraid to acknowledge that if Firefox were indeed to disappear, we’d be royally screwed. We’d end up right back where we started 20 years ago, with Chrome being the new IE6.
    …
    The situation is especially dire for … Linux users, developers, and distribution makers. … Gnome Browser or KDE’s Falkon can barely be taken seriously, and … are based on Apple’s WebKit, which isn’t a great position to be in.


    3. Google’s Return to Work Plan Drops Vaccine Mandate

    Google is planning “celebrations” to welcome back employees after being fully remote. And in practice—unlike at IBM—this doesn’t mean a vaccine mandate.

    Analysis: Vocal minority wins—or do they?

    It was just three months ago that Google said it “firmly stands behind our vaccination policy.” What changed? It’s unlikely to have been due to a tiny minority of staff publishing a manifesto.

    Jennifer Elias: Google relaxes mandates

    The company will no longer require vaccination as a condition of employment … as it prepares to bring workers back to the office … at least three days a week for a “hybrid” work model. … The company [had previously] told employees that they must comply with vaccine policies or they’d face loss of pay and eventually loss of employment.
    …
    According to Google spokesperson Lora Lee Erickson … the company dropped the requirement … after removing the Jan. 18 deadline it had set for employees to either get vaccinated or get exemption approval. She declined to provide further details on the policy or the reasons for the reversal.
    …
    Google Real Estate and Workplace Services VP David Radcliffe [said Google] is preparing to begin its 30-day transition period to the hybrid work week if conditions continue to improve. He said his team is planning “celebrations” to welcome back employees. … Unvaccinated employees who are approved to enter offices will still need to follow additional protocols, including testing and wearing a mask.


    It’s too simplistic to say the anti-mandate brigade are also anti-vaxxers. For example, raxxorrax:

    I am vaccinated and HR knows this. … But if they officially demanded a certificate, I think I would have called it quits. Many people don’t have that option [but] there are consequences for such unreasonable demands.
    …
    I understand a mandate for vaccinations in certain occupations relating to health. It is something you have to personally accept if you want to work in the field.


    Although a few others are way over at the end of the bell curve. Greg Jinkerson:

    Don’t get excited, [Google is] still evil and stupid. … Now they’re backing down for some reason, [but] this is barely anything notable as far as a rollback of restrictions. [It] is not any kind of encouraging news.


    The Moral of the Story: Failure is the foundation of success—and the means by which it is achieved.


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Aleksey Kuprikov (via Unsplash; leveled and cropped)

  • Database Migration from Microsoft Azure to Snowflake on AWS: Part 1

    Database Migration from Microsoft Azure to Snowflake on AWS: Part 1

    Technological advancements have increased the demand for enhanced infrastructure with quick deployments. Public cloud providers are constantly upgrading their policies and infrastructure to match ever-growing business requirements. This competition gives businesses the ability to choose the cloud provider(s) that best fit specific governance and cost-effectiveness needs.

    In this blog, we discuss migrating databases from SQL Server on Azure VM to Snowflake on AWS. 

    Understanding the Problem

    Microsoft Azure is a cloud computing offering for Microsoft-managed data centers, whereas Snowflake is a cloud-based data warehousing solution that provides software-as-a-service (SaaS) based on various public cloud providers.

    In this scenario, we need to migrate the SQL Server databases to Snowflake. There is also a need for the migrated data to be put in Snowflake with multiple schemas for database names with the data in the precise and correct form. 

    While Azure supports ingestion from various sources and clouds, it did not support direct egress to other cloud providers. Finding a workable solution for moving egress to AWS-based Snowflake was the first challenge. 

    Our Approach to Migration

    According to the Snowflake documentation, Snowflake has a stage feature that could address the above issue. It is, essentially, a path in which the data files that need to be ingested are stored, similar to the concept of SMB Samba mount. Using Snowflake Stage allowed it to load Azure Blob storage, after which Snowflake could read and ingest the data in flat files. The next step was to move data from SQL Server to Azure Blob storage.

    The Migration Process

    The migration process consisted of the following steps: 

    • Replicate the database schema in Snowflake as per Azure SQL database
    • Set up Azure Data Factory pipeline to create parquet snappy format flat files on Blob storage.
      • Use parquet files for data compression and quick data load in Snowflake
    • Create file format in Snowflake
      • Create or replace file format <file_format_name> type = ‘parquet’;
    • Create Stage in Snowflake
      • create or replace stage <Stage_Name>
      • url='<Azure Blob file/folder path>’
      • credentials=(azure_sas_token= <token>)
      • file_format = <file_format_name>;
    • To verify if files are staged
      • list @ <Stage_Name> ;
    • Finally, load data to Snowflake table from Stage 

    (Note that all parquet data is stored in a single column ($1))

    copy into TEST1

    from (select

    $1:CustomerID::varchar,

    $1:NameStyle:name::varchar,

    $1:Title:city.bag::variant,

    $1:FirstName::varchar,

    $1:MiddleName::varchar,

    $1:LastName::varchar,

    $1:Suffix::varchar,

    $1:CompanyName::varchar,

    $1:SalesPerson::varchar,

    $1:EmailAddress::varchar,

    $1:Phone:name::varchar,

    $1:PasswordHash::varchar,

    $1:PasswordSalt::varchar,

    $1:rowguid:name::varchar,

    $1:ModifiedDate::datetime

    from @ <Stage_Name>);

    Let’s break down the details of each step in the process.

    1. Leveraging Azure Data Factory

    Azure’s Data Factory is a GUI-based tool that facilitates an end-to-end ETL solution and provides a step-by-step guide for building the pipeline. It has Source (SQL server), Target (Blob storage) and the necessary settings for tuning the performance of the pipeline. These offerings made it a perfect solution for the customized needs of this migration project—which was to wrangle the data before exporting to Blob storage. This was addressed seamlessly by Data Factory which is covered in detail in the later section of this blog.

    2. Tuning the Performance of Data Factory Pipeline

    The tricky part of this migration was that while the pipeline was easy to build, utilizing its full potential and deriving optimum performance was a challenge.

    There were terabytes of data that needed to be exported to Blob from SQL, which would have taken weeks to transfer without tuning. After adequate POC, it was found that Data Factory could support dynamic range in reading data from the source.

    Let’s say there is a table XYZ that is 800 GB. As per the approach mentioned above, Data Factory is required to move the huge amount of data into Blobs. With the traditional method, the GUI, by default, writes the data to Blob serially which would be slower.

    Now, if we look at the table XYZ with a column “date”, the 800 GB of data can be partitioned into small sets depending on month or year. This would mean that each partition is not directly dependent on other date partitions and can be written in parallel. This will be quicker and more resource-efficient.

    This can be achieved by using the dynamic range filter which can be only applied by writing the select statement rather than selecting the checkbox of the existing tables.

    3. Using Parquet File

    The exported data needed to be stored in a flat file while maintaining integrity and compression. CSV was the first choice but during POC many challenges were faced while writing the file, maintaining the spaces and new line characters which corrupted data. The Data Factory offered the Parquet format of a file that had a great compression rate (75%) and also maintained the integrity of the data. Parquet was optimized to work with complex data in bulk and thus was suitable for this project. With respect to the above figure, it can be seen that  40GB of data was compressed to 11GB.

    4. Integration Runtime

    For the Data Factory to work, it required more compute power which was facilitated in the following ways: 

    • Auto-Resolve Integration Runtime

    As the name suggests, the compute resources were managed and assembled by the Microsoft data centers and the cost was incurred on a per-unit basis. The region of these resources was automatically decided based on availability. This is selected by default when running a Data Factory pipeline.

    • Self-Hosted Integration Runtime

    This runtime uses the resources that already exist. For example, the self-hosted IR allowed downloading a client program on the machine for the resources required and creating a service and coupling it with the Data Factory.    

    4. Setting up the Self-Hosted Integration Runtime

    This was the best available option as the SQL server was already hosted on a standalone Azure VM, which provided the freedom to use the full capacity of resources attached to it. It included the following steps: 

    1. Setting-up Self Hosted IR

    • For Azure Data Factory to work with Azure VM it needed to set up the Azure Data Factory Integration Runtime
      • In Azure Data Factory, select “Manage” and then “Integration Runtimes”
      • Select “+ New”, then “Azure, Self Hosted”, 
      • Next, select “Network Environment -> Self hosted”
      • Next, give a suitable name to the self-hosted IR
      • Once the IR is created, Auth keys will be presented. Copy these keys
    • Now as per the last screen, a link was provided to download Microsoft Integration Runtime
        • Download and install the integration runtime from the Microsoft link
        • Once installed, enter the Auth Key1 value and register “Launch Configuration Manager”
        • When registered, the self-hosted IR will bind with the data factory
        • Now, install the Java Runtime 64 bit as it is required for the self-hosted IR to work. Refer to this manual.

      2. Create Linked Service in Data Factory

    • Proceed to Data Factory 
      • Select “Manage” and then “Linked Services”
      • Select SQL server as type of service and give it a suitable name
      • Now under “Connect via Integration Runtime” select the created self-hosted IR
      • Put in the server name. It is important to note that the server name should be the same name used to connect the SQL server successfully
      • Put in the credentials and test connection

    In the next blog, we shall look at some of the challenges encountered during the migration, cost-saving actions and our approach to data validation.

  • Merging Secrets Management and Configuration

    Merging Secrets Management and Configuration

    Fresh from picking up $5.25 million in funding, CloudTruth CEO Greg Arnette talks with Mike Vizard on this episode of the View With Vizard about why configuration and secrets management need to converge. The video is below, followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    Mike Vizard: Thanks for the throw. We’re here with Greg Arnette, who’s the CEO for CloudTruth, they just raised $5.25 million to help us with these configuration issues that seem to plague us. Greg, welcome to the show.

    Greg Arnette: Thank you. It’s great to be here, and thanks for the opportunity to tell your audience about CloudTruth.

    Mike Vizard: So, what is the configuration problem, and why does it not seem to wanna go away? It’s been around for a while, things appear to be getting worse, and what’s to be done about it?

    Greg Arnette: Exactly. So, that ties into the history of founding this company. Both myself and my Co-founder were prior CTOs and DevOps leaders for several cloud-based SaaS companies, and we saw that our DevOps teams were continuing to build internal tools to address issues around configuration sprawl and complexity. And these tools tend to be the weak links in terms of solid deployments, good up time, good security, and basically, slows teams down.

    So, the history of kind configuration sprawl and what we see as the challenges is sort of driven by a number of macro trends—first, the fast rise of Kubernetes; everyone wants to get on the Kubernetes bandwagon. That introduces new complexities around configuration management, new sets of tools that haven’t been sort of well adopted inside of DevOps shops. Another trend is the breakup of monoliths to microservices adds lots of new dimensions on configuration complexity. And then there are the traditional needs around provisioning infrastructure, configuring your apps, and managing secrets are the sort of legacy challenges around configuration management. And as the cloud gets more mature and with more capabilities, configuration is not getting easier, but getting more difficult.

    So, CloudTruth is here to address those concerns. We heard, during our product market fit research where I interviewed over 500 cloud and DevOps leaders on their challenges managing configuration, that this over reliance upon tribal knowledge in terms of how a system is configured and why it’s configured a certain way is just held in key team members’ heads, and that’s not a very durable strategy for going forward or for on boarding new folks. So, there’s an element of CloudTruth that provides collaboration and sharing around configuration settings and context to help reduce that need of, or that sort of burden of the cognitive load to keep track of how are things configured, where is the data, how can I change it, what changed recently—that type of thing.

    Mike Vizard: You guys also acquired a company in this process in the secrets management space, so where does configuration and secrets management converge and how do we think about that?

    Greg Arnette: That’s a great question. So, we acquired Tuono, we’re thrilled to bring in the Tuono team, including Jesse St. Laurent, who was the CTO, who joins us as our Chief Product Officer. Jim King, Mike Healey, Mike Stack all joined us, they were the founding engineers at Tuono.

    And what we did was, we took the Tuono secret management engine, which was cloud native and we’ve now included that in the CloudTruth platform which rounds out our offering. So, CloudTruth, while it is also a configuration data hub to synchronize your configuration settings from all these multiple tools is also itself a parameter store and secret store that customers can use if they don’t already have existing parameter stores or secret stores in their environment.

    Mike Vizard: And in that context, what does cloud native mean? Because some will people say, you know, it runs in the cloud; other people will say that it only runs on Kubernetes, it’s optimized for microservices and containers. Or is there some middle ground there and what do we think about cloud native—what context are we using that phrase?

    Greg Arnette: Yeah, when we use cloud native, we mean or refer to the capabilities that are provided as part of core services at Amazon, Azure, and Google. So, an example is, Amazon themselves provide a parameter store, they call it AWS Parameter Store. Google and Azure provide the same kind of internal capabilities. Customers can also bring their own parameter store, like run something like Console on top of the cloud or using Vault sometimes as a general-purpose parameter store.

    So, the cloud native offerings like AWS Parameter Store, Secret Manager, and the equivalent on the other clouds are things that customers can use, they have different price points. We provide a layer of management and visibility and observability to all that config data stored inside of all these different systems.

    Mike Vizard: And when you talk about unifying configuration, are we replacing Terraform and CloudFormation, or are we just finding some way to layer some form of abstraction around them that makes the whole process easier to manage? Walk me through that a little bit.

    Greg Arnette: Yeah, you know, we’re not replacing Terraform or CloudFormation. We’re designed to coexist with the customers’ existing investments and their configuration tooling. So, whether it’s provisioning tools like Terraform, CloudFormation, Pulumi, or app config tools like Ansible, Puppet, Chef, Saltstack, or secret tools like Vault or the cloud native versions of those capabilities. We coexist and become a metadata wrapper around those different tools.

    Now, if customers don’t have some of those capabilities, we have functionality in our platform that can fill the gap, but more and more customers already have these systems in place. They’re not looking to rip everything out and replace it, but they’re looking to address these issues around configuration sprawl that leads to a misconfiguration causing unplanned down time or a security incident.

    Mike Vizard: We have been talking about DevOps and DevSecOps forever, and the idea has always been that we’re shifting more responsibility for the IT environment to the left of the developer. Sometimes they like that, sometimes they don’t.

    But I wonder, are we not approaching some sort of concern or maybe a backlash where folks are saying, “Hey, you know what? This isn’t really working. We have all this misconfiguration out there, we’re maybe running faster, but things are less secure, and we have more risk than ever.” So, is there a balance to be struck, or what’s your sense of where are we on this journey?

    Greg Arnette: That’s a very interesting question. This is something that we hear all the time in our outreach to our customer audience is what their journey looks like for adopting shift left or GitOps types of operating principles. We’ve seen a number of patterns emerge over our hundreds of interviews. Specifically, most teams do want to give developers more capabilities to do things themselves and reduce that burden on the Ops team, but they still want Ops or DevOps teams to have the overall sort of judgment and enforce the guardrails that were put in place by the security and compliance teams and by the other teams that are sort of deciding what are the best practices.

    So, with CloudTruth, we’re kinda serving both audiences in a purposeful way. You have centralized control and visibility that DevOps wants. They wanna build and enforce lockdowns, enforce default settings that can only be overridden with a permission or an override that’s allowed as part of a workflow. But you also provide capabilities for core developers to manage the config for their own environments and to suggest configuration changes that then can be adopted more system wide.

    So, we’re serving that duality that exists today. We’re gonna let the customer decide on where they ultimately land about developing shift left principles and moving that direction. But we see a lot of interest in that, and it helps to reduce that—you know, again, that cognitive load and that context switching on the DevOps professionals. Because so many times, they’re being bothered by other folks and other developer teams, like, “What’s the setting for this Redis cluster? Why is our Mongo configured this way? How do I tune my elastic search test cluster to match production?”

    That information will all be self-serviceable and findable inside the CloudTruth platform. And our role based access control permissioning system allows view only, read only, read/write access to the appropriate areas, and then DevOps teams can sort of wall off the production systems from other people having chances of changing those settings.

    Mike Vizard: Mm-hmm. What is the role of the security team as we go forward? It feels like, if we shift everything left to the developers, what are those guys doing?

    Greg Arnette: They still need to be involved in terms of ensuring that no bad information gets in and no good information gets out. So, we provide a number of views into configuration data that are helpful to security teams. First is, what changed most recently in terms of your compliance management reports for SOC 2 and other requirements and keeping track of changes. That’s really hard in a dynamic environment, especially cloud-based where you have microservices firing left and right, coming up and down. The old traditional CMDBs that were popular in the on prem world don’t really fit well in the new way that we’re using the cloud.

    And so, CloudTruth is a self-documenting change management control system that is, behind the scenes, keeping track of all the version settings of every configuration value that we’re monitoring, and then we provide views into that data that can be consumed by the security or compliance teams to get better insights for their needs without having to bother the DevOps teams.

    Mike Vizard: Do you feel like the bad people, otherwise known as cyber criminals, are getting better at scanning for misconfigurations and looking for these vulnerabilities to exploit? And we hear a lot about software supply chains these days—it seems like, in a lot of cases, the root cause of the problem is just misconfigurations.

    Greg Arnette: It’s true. We’ve found, in our own research, that 75 percent of unplanned down time or security incident was caused by a misconfiguration when you ultimately read the root cause analysis and do all the internal tracing.

    So, what we wanna provide are the best practices as early as possible in the software development life cycle process to implement good config hygiene. And then secondary to that is, once config is out there in the wild, provide monitoring and insight into how it could affect security vulnerabilities or security posture. Since everything these days is defined as infrastructure as code, it’s all about analyzing all the different locations where config values are stored, making sure those are secure and locked down, and then being able to use any kind of pattern recognition to understand where certain areas can be vulnerable to being taken advantage of by the nefarious factors out there in the world.

    Mike Vizard: Do you think we’ll get to the point where we can use automation to kinda get ourselves out of this mess? We have APIs and CLIs and everything else that’s out there—shouldn’t we, at some point, have enough intelligence in the work flows to say, “Hey, this thing you’re about to deploy is misconfigured, so don’t do it”?

    Greg Arnette: That’s part of our goals down the road is, we have a very thoughtful strategy how we wanna launch CloudTruth as a full configuration data management platform. So, the first goal is to get inserted into a company’s work flows where we have access to the data and can provide value with reports and work flows. The second goal is then, once we’re now managing this data on behalf of the customer, to apply AI and ML, looking for patterns, recommending optimizations, best practices, vetting what we see from a customer perspective against best practices being published by other standards bodies that are looking at this from different perspectives.

    One goal of CloudTruth is to be that configuration data layer management system that we think most companies using the cloud need these days.

    Mike Vizard: We also hear a lot about artificial intelligence—will that get applied to this space? Is there any scenario where we’ll just have a bunch of machine learning algorithms running around, figuring out what’s going on?

    Greg Arnette: We firmly believe that that is definitely gonna be happening a few years down the road. I think the maturity model is just getting started. The first act in getting that up and running is getting access to the data for trending the models and analyzing the trending results, optimizing the model. So, a full observe-orientate-decide-act OODA loop is involved here in terms of making sure those models are accurate, but we think that’s gonna be a big benefit in what we can provide down the road.

    Mike Vizard: So, what’s your best advice to folks? What should they be focusing on today to get to that nirvana tomorrow? Is there same way I should be organized, is there some way I should be talking to my developers? What do you think?

    Greg Arnette: There’s a couple themes that come to mind. The first is—which sounds almost obvious these days—is make sure you are able to do infrastructure as code ideas at all levels that you can, and that’s tied into automation. So, it’s a big portion to continuous deployment, CI/CD pipelines. Once you start the development of those types of workflows that accelerate getting what developers are creating out in front of the customers, whether it’s an internal app or external SaaS or mobile app, accelerating that team velocity is really a key element in terms of making that possible.

    The other area is this notion that you wanna implement systems that reduce the amount of copy and paste. So, that’s what we call the Do Not Repeat Yourself, the DRY approach to infrastructure as code management. So, that’s a key theme behind CloudTruth is, we provide capabilities that let you manage your multiple environments with the faults, inheritances, and overrides from a centralized capability, but still allow flexibility in your environment tree to manage certain sub-environments in different ways as needed.

    So, different developers can have their own custom environment, but they’re gonna inherit default values that are sanctioned by the architecture team or the security team. And then the overrides have to be allowed by a permission basis.

    So, there’s a couple sort of themes that are coming together as we go through 2021 around automation, infrastructure as code, shift left, and the DRY approach to managing input values to all the IAC tools.

    Mike Vizard: Hey, Greg, thanks for being on the show.

    Greg Arnette: Thank you very much. Have a great day.

    Mike Vizard: Alright, awesome. Hey, guys, we learned a lot about security there and things we didn’t know and—hey, there’s hope for the future. Back to you guys in the studio.

    [End of Audio]

  • Updating and Managing Infrastructure-as-Code (IaC)

    Updating and Managing Infrastructure-as-Code (IaC)

    Infrastructure-as-code (IaC), often embodied by open source Terraform, is an essential ingredient to cloud and cloud-native strategies. But without the ability to scale, secure and manage IaC, you very quickly experience drift. Tim Davis, DevOps advocate with env0, pronounced “N zero”, discusses establishing a single source of truth and reigning in drift by updating and managing infrastructure as code. The video is below, followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    Mitch Ashley: I have the pleasure of being joined by Tim Davis. Tim is DevOps Advocate with env0, and so, we’re going to be getting into some infrastructure as code type discussions, so, looking forward to that. Welcome, Tim—good to be talking with you.

    Tim Davis: Same for you, Mitch. Great to meet you. Thanks for having me.

    Mitch Ashley: You, too. I love your cloud off to your right shoulder, by the way. [Laughter] Anyways, so—introduce yourself, tell us a little bit about env0.

    Tim Davis: Absolutely. So, I am the DevOps Advocate with env0. dnv0 is a TACoS platform, if you will, the Terraform Automation and Collaboration Software space. We really focus on infrastructure as code, automation, teams and governance, and other tools to help you with the life cycle of your infrastructure as code environments.

    Mitch Ashley: Cool. Good. Well, you know, it’s a great conversation to have, because something that I observed always happens in our industry is, you create a new technology, it’s kinda easy to get started and starting to use, sometimes it isn’t always easy, but the complexity comes—alright, how do I scale this? How do I do this across a larger development team or multiple development teams? How do I operate it? How do I secure it through the day two kinda stuff?

    Tim Davis: Right.

    Mitch Ashley: And I wouldn’t be surprised if you told me the same is true for infrastructure as code, and in fact, I know that to be true.

    Tim Davis: [Laughter] Exactly right.

    Mitch Ashley: Let’s talk about that. What are some of the challenges once people get into doing infrastructure as code, particularly with Terraform? What are some of the challenges that you run into?

    Tim Davis: Yeah, and most of those kind of lie around the visibility and kind of the control space of that. Infrastructure as code is great. It is a fantastic way of speeding up, kind of pushing yourself into the future for DevOps, getting into that real GitOps life cycle. But with that, you know, if it usually just starts out with either one developer or one infrastructure person that starts running it locally on their laptop and figuring it out, it’s great, it does what they want.

    As soon as you start to scale that methodology and doing it locally to multiple people, that’s when you start losing that visibility of, “Where are my state files stored? Who just deployed something into the cloud? What variables might they have used for that?”

    So, it really becomes kind of an, “I don’t know who’s doing what in my cloud anymore.”

    Mitch Ashley: Mm-hmm.

    Tim Davis: So, really making sure that you’re staying on top of that, kinda centralizing everything to maintain that visibility is very important when you’re scaling it.

    Mitch Ashley: Let me ask you, then—is it fairly typical that within one software Dev team you have a person or sort of a close enough coordinated group of people that are doing the software as code, infrastructure as code. And then the confusion may exist as you start to go across multiple teams, or does it also occur within one team, just sometimes, it’s every developer for themselves and so—

    Tim Davis: Yep.

    Mitch Ashley: – you could have a wild, wild West kinda situation before you know it.

    Tim Davis: [Laughter] And the answer of that, of course, is yes, I mean, it’s all of the above. It could be even just two people on a small team that start to use these tools and they start to step on each other’s toes by having deployments that kind of counteract each other. Or you have it where somebody is deploying out into the cloud using your infrastructure as code and somebody else is just going into the cloud and clicking around and deploying stuff manually where you get something called drift, where what the infrastructure as code says is out there isn’t necessarily matching with what’s actually there.

    Mitch Ashley: Mm-hmm.

    Tim Davis: So, it can be across a single team, multiple teams—any time you really scale it past a single person on a laptop is really where you start to see those issues.

    Mitch Ashley: Yeah, okay. It’s a familiar problem, right?

    Tim Davis: [Laughter] That’s exactly right.

    Mitch Ashley: We’ve had this in other things, too. Well, what are some of the best practices or kind of good infrastructure as code hygiene to keep your worlds at least sane to start with so you—the first question is always, “What’s there?” If you don’t know what’s there, then—

    Tim Davis: Right.

    Mitch Ashley: – everything is up for grabs, or you question everything because you just don’t feel like you have a good grounding of what you’re looking at and what you’re dealing with. What are some of those best practices?

    Tim Davis: And I really—I try to stay away from the best practices thing, because sometimes what’s good for somebody isn’t great for somebody else, but that—

    Mitch Ashley: Well, and I say that as best practice is not universal, right?

    Tim Davis: Absolutely. And there are some things that you can do to help yourself out, for sure. If you’re using infrastructure as code, having the single source of truth can be very helpful for everybody, essentially stopping that drift that I just mentioned. So, if you are using infrastructure as code, save them in a repository somewhere. Make that the single source of truth where whatever’s in there, whatever’s in those infrastructure as code files, that’s what’s there.

    So, whenever you decide to go for infrastructure as code, stop using the cloud UI, stop going around and click, click, clicking and adding resources and things. Do it by updating the infrastructure as code file and then re-deploying. That can really help you make sure that you’re not causing any problems, nobody’s stepping on anybody’s toes, and you know if I see it in the files here in this one spot, that’s what’s out there.

    Mitch Ashley: Mm-hmm. Yeah, I totally agree with you. That makes a lot of sense to me. What are some of the complexities, then, you have to deal with? Because now we’re working an environment where infrastructure, the stack, the distribution of that, the locations, whether geographic or service provider really can change instantly without necessarily the full development team, which is an advantage, right? You want that sort of abstraction.

    Tim Davis: Exactly.

    Mitch Ashley: But it also can be—introduce new variables and maybe even new problems.

    Tim Davis: Yeah, and it could be new problems, it could be the same old problems, or it could be new problems that you kinda deal with the same, old way. And, you know, adding controls of making sure you’re adhering to policy, like, you’re only allowed to deploy to certain regions or you’re only able to deploy a certain number or size of instance, making sure that you have some form of role based access control there to know, you know, this person is allowed to deploy straight out to development, no problem, but if it’s going to production, it needs to wait for approval and somebody from either the DevOps team or the SRE team needs to validate everything first before we actually make that push.

    Mitch Ashley: Mm-hmm. I think something else that always happens, too, is in—you know, I’m a security guy as well as a software guy, so, I always worry about the security side of it. Now, automation can make that, you know, much better.

    Tim Davis: Exactly right.

    Mitch Ashley: Much more reliable, less human error. There’s a lot of good things that come with infrastructure as code from a security standpoint, but it also can be, it’s sort of security is in the eye of the scripter and the person who’s—

    Tim Davis: Right. [Laughter]

    Mitch Ashley: – doing, you know, configurations or doing the scripting, too, which can be good or bad. How do you address security in this kind of a world?

    Tim Davis: Yeah, and this is just one of those things where we’ve all heard the term shift left, and shifting all of these different things—security, performance, you know, billing—everything, if you shift it left into the deployment process, it really helps if you foster that communication. I mean, we know that old school term of silos where one hasn’t isn’t talking to the other hand. If everybody gets involved, if the security team is involved with writing the policy, they’re involved with double checking that it is implemented into the deployment process so that you don’t have to go and fix a problematic deployment later, it’s just stopped before it starts. That can really make sure that everybody kind of gets what they want, but security folks still have to be involved. They are still in charge of the overall process and procedure and policy, it’s just, it’s kind of a new way of getting that implemented and at what stage of the life cycle you’re implementing it.

    Mitch Ashley: Do you think it shifts—and this is actually, I just did a talk on this about shifting left of, we wanna shift everything left, which is generally a good idea, right?

    Tim Davis: Right.

    Mitch Ashley: To be able to address some of those things early and design it in, design security in, et cetera. Oftentimes, it’s interpreted as, “Let’s put that on the developers, too. Let’s have them—the developers will worry about that. The developers will worry about all those.” Now, it’s pretty much, it could be everything, sort of a ridiculous request, right?

    Tim Davis: Right.

    Mitch Ashley: Because that’s not a developer’s expertise to necessarily know all those things. What is your—when you say shift left or infrastructure as code—

    Tim Davis: Right.

    Mitch Ashley: – in practical terms on a software team, what does that look like?

    Tim Davis: Yeah, and a lot of folks think that that just means, “Hey, I’m taking away your job as the security guy and I’m gonna give it to the developer” and that’s not the case. The developer, they may be a little security conscious, they may understand the infrastructure or the networking piece, but nowhere near as much as the career security guy or the career networking and infrastructure guys. It just kind of brings them in and fosters that conversation.

    I definitely think the developers are going to be part of the conversation, because it is bringing it into their tooling, into their languages, into their life cycle, but it still requires that expertise to be able to make sure that it is done correctly, it’s implemented correctly, and that it’s being checked the way it needs to be done.

    Mitch Ashley: Mm-hmm. So, does it look like security engineers, to use that as a term, they’re sitting down with the developers, saying, “Okay, how are we configuring the environment?” and, “Here’s how you’re building your Terraform configurations”—going through that with them?

    Tim Davis: I think so.

    Mitch Ashley: Is it saying, “Here’s the principles we want you to follow”—

    Tim Davis: Yeah.

    Mitch Ashley: – “and as you’re creating this, please do these things, and then we don’t have to sit on your shoulders”?

    Tim Davis: I definitely think there’s lots of different ways you can do that. I mean, obviously, you know, having your standup meetings, making sure that they are kinda telling them, “This is what the policy should look like, however you want to implement it is fine, but this is the kind of processes and procedures, these are the rules that we need to check.” So, it can definitely be done however works best for everybody, but as long as you’re having that communication and you’re making sure that everything’s going through—yeah, you know, you can always do it different ways and be successful, still.

    Mitch Ashley: Mm-hmm. Interesting. What are some of the things that you’ve seen change? You know, there’s been a lot of acceleration over the last 12 to 18 months.

    Tim Davis: Right.

    Mitch Ashley: And, you know, I’ve heard people talk—of course, you always hear about the, as much digital transformation happened in the last year that was planned for five years.

    Tim Davis: Yeah.

    Mitch Ashley: And there is some truth to that, and I’m sure some exaggeration, too. But there’s a strong belief that, you know, people are now thinking they can deploy applications much, much faster and they’ve proved it in this last window. Have you seen that happening?

    Tim Davis: Yeah, absolutely, and you know, technology changes. They used to say it doubles every six months or what have you, and really, we are iterating and changing and kind of moving forward very, very quickly. A lot of times, we get a new tool and it’s great and then people are like, “Alright, I’m gonna pull this tool in and automate it” and then they figure out, “Oh, there’s some extra complexity here and we’re having to go back through and figure it out.”

    I definitely think there’s a lot changing, you know, even just the shift from on prem legacy, I guess, enterprise architecture through to new, like, cloud native architectures and things like that. We’re moving fast, we’re able to change and pivot and do what we need to do, but as long as we make sure that we’re kind of keeping grasp of what we’re supposed to be doing from either a security or an infrastructure construct, we can make sure that we can iterate and change and adapt as fast as possible without causing any major issues down the line.

    Mitch Ashley: Mm-hmm. Cool. What do you think the next 6 to 12 months look like? If you had to put on your crystal ball, your Magic 8 Ball, that says, “Ask Again”?

    Tim Davis: [Laughter] Yeah, I love to look into that. Obviously, it’s good to see, you know, what am I gonna have for lunch next week, but also, you know, looking into the industry of what’s gonna happen. We’re seeing more and more X as code. We’ve got infrastructure as code, you’ve got security as code, you’ve got policy as code tools. I think we’re gonna see more and more and more, you know, performance as code and things like this that just are able to bring those day two plus operational tools closer left into the deployment cycle and have all of these single source of truth in the repositories of, we know exactly what our infrastructure is supposed to look like, we know how it’s supposed to be secured, we know how it’s supposed to perform. All of this is just declaratively set up there. I think we’re gonna see a lot more of that going forward.

    Mitch Ashley: Mm-hmm. Well, certainly, as you said, it follows the “everything as code,” right?

    Tim Davis: Exactly right.

    Mitch Ashley: And if we’ve learned nothing else, I think that’s been a lesson of the past 12 to 18 months, right? It is software, it’s all about software.

    Tim Davis: It absolutely is.

    Mitch Ashley: What do you think some of the skill challenges are for people as we continue to evolve this and move into this rapid world, shifting things left, doing more infrastructure as code, and maybe asterisk as code—everything? You know, it’s always the self-learners can be at the edge of the curve, other folks have other ways of learning. How do we bring everyone along in terms of their skills and their learning, their development?

    Tim Davis: Yeah, and that’s definitely something. I mean, I ran into myself. I’m an infrastructure guy at heart, that’s where I’ve been, you know, my whole career, and eventually, someone was telling me, “Hey, this Python thing might take off” or, “I’ve heard of this thing called Terraform and it’s basically like code, but it’s our job.” And, you know, just realizing that nobody’s trying to take away your job as a security guy or an infrastructure guy or girl or what have you. They’re not trying to take it away from you and move it over to a developer, it’s just one of those things where you need to adapt to move forward faster.

    Now, it’s not just infrastructure folks that are learning to code, it’s also developers that are kind of learning infrastructure and figuring out how can I optimize my application against this infrastructure a little better? How can we work together to move forward faster? So, it’s kind of a melding of skills from different, you know, old school silos now to work together to solve the problem.

    Mitch Ashley: I made that recommendation to a network and security engineer about 10 years ago. It’s like—learn Python, and he looked at me like I had six eyes instead of two.

    Tim Davis: [Laughter]

    Mitch Ashley: And he came back from the Cisco conference, he goes, “Now I know why you said that.” [Laughter]

    Tim Davis: Exactly right. And that’s a great piece of advice even today in 2021. I mean, if you’re in infrastructure or you’re a network tech or you’re a security person, look into Python. It’s not as hard as you think and you can do so much with it. It’s a fantastic way to kind of break into that DevOps automation type space.

    Mitch Ashley: I like that, too, and not that we’re trying to make everybody a developer, but if it’s not a skill you have, it sort of leaves out this whole domain of things that you can either do to understand what’s happening—

    Tim Davis: Right.

    Mitch Ashley: – or do to automate or et cetera. It’s sort of like you’ve got one arm tied behind your back, why don’t you have two out in front where you can fully work?

    Tim Davis: Yeah. And it also helps from a cohesive understanding between groups. Back when I was a dedicated infrastructure person, myself and the development team didn’t care for each other, because we all were trying to get in each other’s way, it seemed. We were trying to solve the same problems, just going about it in different ways, because we didn’t necessarily understand the methodologies or how those people were trying to get their work done.

    If you as an infrastructure, security, or other operations person start to kind of learn the development methodologies and figure out how things work, it’ll help you to communicate and solve problems across teams better, simply because you kinda see where they’re coming from with their tool sets and the way that they do business.

    Mitch Ashley: Great. Well, it’s been a great conversation. I’m glad we got to explore this path together.

    Tim Davis: Absolutely.

    Mitch Ashley: Where can folks find out more about env0? I know you have a kind of funky spelling of env0.

    Tim Davis: [Laughter] Yes. We are at env0, E-N-V and the number 0.com. You can find us on Twitter @E-N-V-Z-E-R-O and on YouTube at E-N-V-Z-E-R-O.

    Mitch Ashley: Great. So, environment zero, right?

    Tim Davis: Exactly right.

    Mitch Ashley: Perfect. Well, hey, it’s been fun talking with you and hope you’ll come back again.

    Tim Davis: That sounds great. I look forward to it. Great to meet you, Mitch. Thanks for the time.

    Mitch Ashley: Alright, take care.

    [End of Audio]

  • The Past, Present and Future of OpenStack

    The Past, Present and Future of OpenStack

    OpenStack, described as the world’s most widely deployed open source cloud software, will mark its 12-year anniversary milestone later in 2022. In September 2012, the OpenStack Foundation launched as an independent organization to manage and promote the technology—a watershed moment for a project announced just two years earlier.

    Today, with contributions from more than 34,000 people at 550 companies, OpenStack is one of the three most active open source projects, alongside the Linux kernel and the Chromium web browser, according to the group now known as the Open Infrastructure Foundation (OIF). More than 25 million OpenStack cores are running in production worldwide.

    It’s easy to forget that only a few years ago many predicted OpenStack’s demise. Initially, OpenStack was positioned as a general-purpose private cloud platform that offered an open source alternative to Amazon Web Services (AWS), but it never stood much of a chance in that matchup.

    Then, after OpenStack regained momentum and pivoted to become a platform for telco network function virtualization infrastructure (NFVI), it was rumored that it would be overtaken by the new ‘next big thing’—Kubernetes, the open source orchestration and coordination system for containerized applications. 

    The Kubernetes-as-OpenStack-killer talk was silly, in retrospect, because the technologies are complementary, not competitive. In fact, more than 70% of OpenStack users reported running Kubernetes on top of OpenStack for container coordination, according to the OIF.

    And OpenStack adoption should continue to flourish in 2022. Gartner forecasted that global spending on cloud services will exceed $480 billion this year, up from $313 billion in 2020, as more organizations invest in hybrid cloud: A mix of pay-as-you-go public clouds and private clouds that can offer lower, more predictable operating costs and greater customization. As the hybrid cloud market expands and open source continues to become more firmly entrenched in development and IT organizations, OpenStack is more relevant than ever.

    If you’re not familiar with OpenStack, here are 10 things you should know about its past, present and its future.

    1. OpenStack began in early 2010 as a collaboration between Rackspace and engineers at NASA’s Ames Research Center in Mountain View, California. Rackspace wanted to rewrite the infrastructure code running its cloud servers and the NASA team wanted to standardize the space agency’s websites. Their original mission was “to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable.”

    2. The first OpenStack design summit was held in Austin, Texas in July 2010, and the project was officially launched at the O’Reilly Open Source Convention (OSCON) later that month.

    3. A whopping 80% of OpenStack clouds are used in production, while 13% are under development and 8% are in the proof-of-concept stage, according to the OIF. With that level of adoption, no wonder OpenStack is considered the most widely deployed open source cloud software.

    4. An OIF survey showed that nearly half of the organizations using OpenStack have deployed at least 1,000 cores. The breakdown: 29% of organizations have 1,000-9,999 cores, 13% have 10,000-99,999 cores, 6% have 100,000-999,999 cores and 1% have one million or more cores.

    5. An enormous corporate ecosystem supports OpenStack, including IBM, Red Hat, HP Enterprise, Intel, Huawei, NEC, Cisco, VMware, AT&T and Canonical, whose Ubuntu Linux distribution is the most popular operating system for OpenStack deployment (used by about 40% of OpenStack clouds globally).

    6. OpenStack has a great resource guide available on openstack.org with all kinds of helpful information for developers, including for those new to the platform.

    7. One of the main qualities people love about OpenStack is that it’s a modular architecture with interconnected components including, for example, services that expose API endpoints and handle basic cloud functions, a dashboard, SQL databases that store records created by OpenStack services and message queues for facilitating inter-process communication. 

    8. OpenStack jargon includes several special terms. A tenant, for example, is a user or group of users with isolated cloud resources. (OpenStack is multitenant.) An image is a template containing an OS for instance provisioning. A flavor is a template defining cloud resources for instance provisioning. An instance is a virtual machine (VM) provisioned from the image and flavor. And so on.

    9. The platform has expanded through the years to include a panoply of core services, such as the Keystone identity service that manages domains, projects, roles, groups and user accounts, the Glance service that manages the catalog of cloud images, Nova for instance provisioning, scheduling and termination, the Neutron network service and the Cinder block storage service.

    10. Beyond these core services, several newer services are seeing increased adoption. For example, according to the OIF, use of Ironic, a project that provisions bare metal, nearly tripled between 2016 and 2021. Others with growing traction include Octavia, which provides load balancing capabilities, Manila for file system sharing between instances and OpenStack Charms which provide rich life cycle management capabilities for services.

    As these 10 points show, far from being on its deathbed, OpenStack has survived, sometimes against the odds, and thrived as a unique force in open source and cloud computing. Given its journey over the last 10 years, it will be interesting to see what lies ahead in the next decade.