devopsy.kinsta.cloud

Tag: kubernetes

  • Know What You Want and Need

    Know What You Want and Need

    Over the years, what we purchase from vendors has changed significantly. It used to be that IT would define a need, go out and find a bit of software to solve it, install and configure the software and, in most cases, spend the majority of time on the project getting it to work correctly in their environment. Those days are largely gone. First, we started buying appliances for some functionality, then we started using MSPs for some or all functionality, then some vendors wanted to deliver in a VM where they could make configuration much easier by controlling the environment. That was the first step to virtualizing purchases. Then we started looking at infrastructure-as-a-service (IaaS), then SaaS, then some vendors offered PaaS … Currently, all of the cool vendors are offering containers—which are an improvement over VMs, and offer a virtual appliance that is quick to get running and tested to do what it was purchased for. Or at least tested to do what it was sold for. We’ve all got stories about what we did with these purchases that were “off label”—things that a product really wasn’t designed for. Along the way, we also introduced open source vendors; a bit of an oxymoron that really described service orgs that base their product on an open source project. Some far more successfully than others.

    And all of that, dear reader, is why we are here. Before purchasing, there is a lot more to find out than there used to be. What, actually, is the product this software vendor is selling? In the end, IT is looking to solve a problem. Most of the time, whether that problem is solved by SaaS, local install or cloud instance is less important than how well the problem is solved. But implementation—and licensing—are important to an organization if not immediately, then over the long term.

    When purchasing an open source “product”, you’re … actually not. You are getting the product and purchasing support. Since open source can be hacked to run just about anywhere given enough time, more than one OSS vendor has pretended that makes them superior to commercial products targeted at a specific platform. That is blatantly untrue—unless the OSS vendor is supporting the product anywhere and everywhere which, of course, they are not. I can port the OSS project MyFunApp to any platform I want without paying for support that won’t do a thing for me when I get it up and running on OS/2 (as an extreme non-existent example).

    SaaS has more issues when it comes to TCO. While pay-as-you-grow is cool and all, locking in a monthly payment forever is a big step and should be considered. And at an enterprise, “forever” needs to be considered realistically. Implement a particular SaaS CRM and you are unlikely to move to another, even if you claim that you will in a heartbeat. It’s work. A lot of work. It is definitely possible, but for most organizations, unlikely. So know what you are getting into. And while you are evaluating, don’t forget to consider variable charges, which most SaaS products have. Make certain you understand what the actual monthly costs are likely to be. IaaS suffers this same variability problem, as many of us have learned.

    Containers are a very sweet solution to appliance-like functionality—drop a container into your Kubernetes flavor of choice and move along. The problem here is a combination of proliferation—how many are required? One per pod can get expensive over time, for example. Those resources aren’t free, no matter the platform. The other issue is updates. Automatic updates are the norm for container instance-delivered products. From a security perspective, you should have questions. Updating things in your network should probably require your approval.

    I’m not suggesting that one delivery method is better than others here; I’m simply suggesting that we all need to be more deliberate about those choices than we’ve needed to be in the past. Knowing not just SLAs but the cost and support implications of every choice is important both today and down the road.

    Keep kicking it, and keep picking the solutions that best solve the organization’s problems. Just be aware that sometimes, the issues a delivery method introduces undermine the effectiveness of the solution.

  • Cloud: Why Must We Be Confusing?

    Cloud: Why Must We Be Confusing?

    When I was a kid learning to play Dungeons & Dragons (D&D), the concept of level was never confusing—though the authors should have seen that it very well could be. For those unfamiliar, D&D has many uses of the word level—character level, caster level, spell level, dungeon level and, increasingly, as time went on, monster level. I can almost guarantee that I missed some uses of the word level in the game, but you get the idea.  In fact, if I missed your favorite, feel free to add a comment.

    We used context to determine what was meant, and we clipped along without any (game) world-shattering consequences. Though some people were horribly confused.

    (Side note: I worked with D&D co-creator Gary Gygax for a while and he knew about the over-use but didn’t feel that after D&D’s surge in popularity it could be fixed. His later RPG creations did seek more clarity and less word reuse, but most RPG systems available today still have many uses of the word level.)

    I am comfortable declaring that those of us who grew up on RPGs are now running vendor companies and doing analysis. Otherwise, why would we have so many uses for unique words? I mean, we no sooner got DevOps than we made a total mess about what, exactly, you meant when you said “CD”. Was it continuous deployment? Continuous delivery? Both? Similarly, we malformed continuous integration. Let’s call it CI—and then make an entire market around it really being continuous test while it is still used to refer to continuous integration, because that is not at all confusing.

    But then we jumped to cloud, and spent some time being really busy trying to confuse everyone about what “cloud” actually means. Is it only public cloud, or does it include private cloud? If private cloud, does that include virtual private cloud only, or does it include cloud in a co-host or data center? Is SaaS actually cloud, or is that a completely different beast?

    And that brings us to the reason I came here to write this particular blog post. We are now being barraged with “cloud” that includes Docker hosted on Kubernetes. I think of this as akin to one too many uses of the word “level”.

    Kubernetes is not cloud. It offers similar infrastructure in a smaller format, but the key to Kubernetes is that it supersedes cloud. Kubernetes doesn’t care about your cloud (or lack thereof) once it has been implemented. Cloud simply becomes infrastructure-as-a-service (IaaS) when Kubernetes is deployed. This is terribly important for a variety of reasons, not the least of which is that if you drop Kubernetes onto a cloud provider, you have two sets of infrastructure to lock down. Two sets that have a lot of internet exposure—because it’s not called “public cloud” for nothing.

    I do understand where referring to Docker hosted on Kubernetes as ‘cloud’ comes from; there are a ton of similarities. But Kubernetes needs a platform—hardware or virtual—to run on. And hand-waving the implications of that nested relationship is asking for trouble. And when cloud is either a thing of the past or so totally commoditized that people don’t think about it, Kubernetes or its successors will likely be the reason. So let’s take it easy re-using cloud too much.

    In the short term, though, my advice is that if someone in the industry mentions cloud in their product offering or analysis, ask which use of ‘level’ they mean. Because honestly, Kubernetes, if implemented on hardware or IaaS, can be picked up and moved to whereever it is needed. And that’s not “cloud”.

    Keep kicking rear. Doesn’t matter where your apps are running, it matters that you’re keeping them running and locked down. Keep it up, and call things what they are—container orchestrators are not cloud platforms, no matter which functionality they share. And to all my RPG peeps, keep having fun. There are always new adventures to be had… No matter the level.

    Image: Photo by S L on Unsplash.

  • The Right Tool for the Job: Container Edition

    The Right Tool for the Job: Container Edition

    I have written about “the right tool for the job” repeatedly. Because (again) we are absolutists in IT. My father was an antiques restorer that dabbled in flipping houses and was rather forceful about the “right tool for the job.” When I left the service and joined IT, it was something of a shock to me that the “right tool for the job” was considered situational.

    At the time, there were a large number of Microsoft zealots that loved Visual Basic, and a larger number of non-zealots that preferred C or Java. That was how we got to my first “right tool” article. VB was very strong with regard to UI and record crunching, while to-the-metal was C’s strength and Java fell in between the two—not being perfect at either. So my article stated that. Front-ending databases? Use VB. Writing drivers and low-level processes? Use C/C++. Need a bit of both and easy web page generation? Go with Java.

    It is many years later and time for an article that seems just as obvious to me, but in a different IT space. We have all heard of the three architectures: Data center, cloud and mixed/multi-cloud. We have also heard of how, in this rapidly changing world of DevOps, Agile and containers, different organizations are using different deployment methodologies. That’s all good so far. Just as the variety of programming languages available today is a bonus in many ways, so are multiple deployment and operations options.

    Where it gets sticky is when people include the “We’re an X shop” in conversations. Or try to do everything under the sun with one of these methodologies. For many of us, container infrastructure is perfect. Use an orchestrator like Kubernetes, build systems and security practices, then not have to care much if the Kubernetes instance it runs on is on-premises, hosted or cloud. Of course you have to care some. Networks have to connect, etc. But most of the work is done.

    Then there are the people that have use cases that don’t fit this mold and have not acknowledged that fact yet. This blog is for you. We’ve all heard of companies that have containers whose life expectancy is measured in seconds. Beyond that, I was told about a company that is using containers as message queues. Honestly. Creating a container with a startup command and putting it on a queue. When it is pulled off the queue, it executes that command and then goes away. We’ll call this crowd the “Over Users”.

    Finally, we have the people that cannot or will not be moving their systems anywhere. There are a variety of reasons for this, but these are companies that know their applications will continue to run in the data center for the foreseeable future. We’ll call this group the “No Needs”.

    For Over Users, that is literally what serverless is for. Create a queue with a (much smaller) call to an API in a serverless environment and be done. Fewer configuration issues, less maintenance, less everything but code. Add a trigger, remove entire OS/network/configuration generation and maintenance. The most likely resistance to this advice is “But we have an investment…” Yes. And for most orgs it is an investment in unnecessary technical debt. Divest. Keep the good parts—a container architecture meant to shuffle through many containers that exist for a short time is well-architected.

    For No Needs, before you port everything to containers—which I am generally in total support of—you should consider if you need to; think about if it offers any benefits and what the ROI of such a move is. Honestly. For DevOps-heavy shops or orgs that require highly portable solutions, the ROI of containers is quick and obvious. For orgs whose applications are not changing a ton and are highly unlikely to move anywhere, the ROI is a whole lot murkier. “But it gives us options!” is the most likely negative response to “We don’t need that right now.” But that’s the problem—you have those options now. What it gives you is a shifting of cost from some possible future where it might be needed to today’s already constrained budget. If there is a verifiable need—normally in portability, but any verifiable need—then make the move. Until then, spend that time and money making those apps rock.

    You’re doing it. The lights are on and the applications are useful. Use the architecture that makes sense for what you are trying to achieve. Right tool for the job, as my Dad often said (he said it a bit more forcefully when I thought a chisel was a screwdriver, but that’s a different story). Keep rocking it, and stay focused on need.

  • Build Once, Deploy Anywhere

    Build Once, Deploy Anywhere

    This late in the game, it seems stunning to me that I have to write this, but there are plenty of you who aren’t there yet—so let’s try a different approach.

    A huge part of DevOps is reducing redundancy. We have cut the fat until it hurt, then refocused and cut some more. There is a blog here about burnout, but we’ll save that for another day. The point is, we don’t do the same thing over and over unless there is a quantifiable benefit—like rebuilding and testing new iterations or spinning up base images to start a new project.

    We insist that our applications run in as standardized an environment as possible, with images from a repository and standardized software installed.

    And then we promptly put it into a unique environment where deployment is completely different. Yes, I’m talking about which cloud or which data center; if it’s deployed via a data center, then hardware, virtual machine or container? The work to standardize the important bits and leave the less impactful bits to teams to decide has been astounding on the Dev side of DevOps (for those new here, what I call DevOps), but have been far less effective in DevOps. Even companies that claim to be pure cloud generally have two or more cloud vendors, each of which is doing things differently.

    So, with all of that said, I can say what I should not have to say after all of these years:

    Make containers standard. I don’t care which flavor and management tool you use, but add in that portability layer. It will protect you from a future where your preferred hosting environment (be it cloud, local or hosted) becomes hostile or overly expensive—or simply ceases to exist. And it will standardize the rest of your DevOps processes. Yes, your preferred cloud vendor offers Kubernetes, and no, that’s not sufficient. Kubernetes offerings today are like Microsoft in the 1990s. Embrace and extend to build the lock-in barrier higher. You do get some great functionality from the cloud vendors I pay attention to, but processes become non-standard. Better to limit platform-specific work to “spin up a server” and have everything else be reusable whereever you are deploying. The benefits here are far-reaching; there will be configuration and security issues that are different when you move from cloud to cloud or cloud to data center or data center to cloud, but the core of DevOps will remain standardized. There are tools to help with baseline cloud security and risk management, so those in addition to using Kubernetes as a portability platform will make current work less onerous, and massively increase portability from deployment location to deployment location.

    You’re short of staff. It does not take a rocket scientist to predict that this situation will not change. Adopt the things that will reduce your workload—like DevOps standardization on Kubernetes (or OpenShift or whatever) as a deployment platform—and keep rocking it. You can’t wave your hand and get more staff or hours in the day, but you can implement containers as the sole deployment option to save time. And use those hours to solve other company problems—because that’s what we do, solve problems for the business. And keep smiling, because you’re rocking it. If you weren’t, they’d find someone who could.

  • Civo Report Surfaces Growing Cloud Lock-in Concerns

    Civo Report Surfaces Growing Cloud Lock-in Concerns

    A survey of 100 IT professionals conducted by Civo, a provider of cloud services based on Kubernetes, finds a total of 82% currently rely on either Amazon Web Services (AWS) or Microsoft for public cloud infrastructure. However, more than a third (34%) of respondents also report they now feel locked into the public cloud service provider.

    The primary reason survey respondents cited for feeling that way is data transfer costs are too expensive to move off their current cloud (65%).

    Simply inertia also seems to be a factor. A third of the total respondents (33%) said they had always used the same cloud service provider. Nearly two-thirds (62%) also noted they were concerned that alternative cloud providers would suffer more outages. At the same time, however, 45% of respondents conceded they are under growing pressure to reduce cloud costs.

    Civo CEO Mark Boost said it’s already apparent that cloud outages are not just limited to alternative cloud providers. In fact, most application workloads are relatively simple in the sense they can run equally well with the same level of resiliency on any number of cloud services at a lower cost than the major hyperscalers currently charge, he noted.

    In effect, cloud computing, except for some more complex workloads, should largely be viewed as a commodity, added Boost.

    Cloud service providers, of course, discourage migrations using exorbitant data egress charges that often make moving data off their platforms cost prohibitive. In fact, most applications are deployed on a single cloud versus in a truly hybrid cloud model because data management can become exceedingly complex. Ideally, IT organizations would like to be able to play one cloud service provider off another to reduce costs. In practice, however, once an application is deployed, it rarely moves to another platform.

    On the plus side, however, microservices-based applications deployed on Kubernetes clusters are easier to move because each instance of a Kubernetes cluster exposes a consistent set of APIs. However, stateful applications deployed in Kubernetes environments can like any other application become dependent on, for example, a proprietary database.

    The tradeoff, of course, is that each cloud platform added to an enterprise IT environment tends to increase total costs. IT staffs typically need to hire additional specialists that require tools to manage each cloud. There are, naturally, platforms that span multiple clouds but the cost of acquiring, provisioning and maintaining those platforms can be considerable. In the meantime, more organizations find themselves separately managing and attempting to secure multiple clouds simply because individual departments prefer one cloud service versus another.

    It’s not clear to what degree organizations may soon decide to consolidate cloud workloads as part of an effort to reduce costs. However, a lot of workloads in the immediate aftermath of the COVID-19 pandemic were shifted to the cloud with little regard for cost. Now that organizations are adjusting to the so-called new normal, many of those decisions are, at the very least, being re-evaluated to see what might make the most financial sense as the general economy seems to become less predictable with each passing day.

  • Cloud-Native: It’s One Thing

    Cloud-Native: It’s One Thing

    This Wednesday, August 10, 2022, starting at 9:00 a.m. ET, Techstrong Group is hosting an awesome virtual conference: CloudNativeDay. I am sure most of you already know a lot about the many cloud-native solutions out there; are familiar with the great work the Cloud Native Computing Foundation (CNCF) does and that you have Kubernetes clusters running in your environments. But for me, at first, the interest and enthusiasm people showed for anything and everything cloud-native defied my understanding.

    We do about one virtual conference a month here at Techstrong Group. That may sound like a lot, but when you divide it up among topics in DevOps, cybersecurity, cloud-native and digital transformation and then further segment who in an organization is targeted by those events, it doesn’t give us a lot of room to dive as deeply into some topics as we would like. We pick the topics of our virtual events carefully and we depend on feedback from you, our audience, to guide us.

    Tim Hockin, Principal Software Engineer: Kubernetes, GKE, Anthos at Google

    This is the fourth year we are producing a cloud-native virtual event, so the topic has obviously resonated with many of you. But it wasn’t until this past year that I had the “Eureka!” moment and realized why.  You see, to discover the reason why cloud-native was so popular, I looked in the usual spots: Software, applications and solutions. I felt confident that Kubernetes’ popularity was one of the reasons cloud-native was so popular. Over the last 24 months, observability burst on the scene. Maybe that was driving the continued popularity of cloud-native. Heck, the CNCF has over 40 projects; perhaps the sheer quantity is what makes cloud-native so popular. But none of that felt exactly right—yes, all of these things drive cloud-native’s popularity. But they aren’t the key driver.

    Once again this year, I had the pleasure of recording a fireside chat with Tim Hockin. If you don’t know him, Tim is a principal software engineer at Google and an original member of the team that brought Kubernetes out from Borg (if you don’t know Borg, then you need to learn some cloud-native history). This is the fourth year we have Tim keynoting this virtual conference, and chatting with him is always a highlight of the event for me.

    Tim said something in our conversation this year that finally made it click for me. Suddenly, I had found it. The “one thing”, in the immortal words of Curly from the movie City Slickers.

     

    You see, the secret to cloud-native isn’t how great and powerful Kubernetes is; it’s not what observability or service mesh or any of those great cloud-native or CNCF-developed software tools can do for you. Cloud-native is a state of mind. As much as it is about software, it is also a state of mind. Cloud-native is about building powerful, applications at scale using the entire ecosystem that was created as a result of that state of mind.

    Sound a little too zen for you? Well, I hope to change that thinking. You do not want to miss my conversation with Tim Hockin that kicks off our show this year. We’ll discuss the belief and help you understand why cloud-native is a state of mind. And, while you’re listening, Tim and I also talk about what is new in fleet and multi-cluster Kubernetes.

    The entire virtual event program is chock full of great sessions. Head over to the event site and see for yourself. Panel discussions, speakers, demos. Great exhibitor booths you can visit and ask questions. Games, prizes, a DJ, a mixologist and more. We can’t wait to see you there!

    And if you remember anything from the event, let it be this one thing: Cloud-native is a state of mind.

  • Datadog Enhances Monitoring and Security for Kubernetes

    The new offerings help organizations easily manage the increasing complexity of Kubernetes environments

    NEW YORK, NY, May 16, 2022 — Datadog, Inc. (NASDAQ: DDOG), the monitoring and security platform for cloud applications, today announced a number of enhancements to its platform that simplify the monitoring and security of Kubernetes environments.

    While orchestrated container environments are growing in overall adoption, they are also becoming increasingly time consuming and difficult to manage. To address this complexity and help companies more effectively monitor and secure their Kubernetes environments, Datadog has launched a number of new platform enhancements specifically for Kubernetes users:

    • Container Monitoring: Datadog Operator for Kubernetes, Amazon EKS Blueprints Add-On, Helm integration, and OpenTelemetry Span Ingestion support greatly simplify setting up monitoring in Kubernetes environments. With these enhancements, Kubernetes users can easily deploy and update the Datadog Agent without downtime, get deeper visibility into the health and performance of their dynamic infrastructure, and monitor their entire set of resources using Datadog monitors, dashboards and SLOs.
    • Application Performance Monitoring: APM Service Pages now include detailed pod information. This allows customers to quickly identify issues impacting their containerized applications.
    • Security: Using Cloud Security Posture Management and Cloud Workload Security, Datadog customers can now continuously monitor their Kubernetes clusters for critical misconfigurations, report on CIS benchmarks and detect attacks against Kubernetes infrastructure in real time.

    “Our 2020 research showed that Kubernetes was the dominant container orchestration platform among our customers. That trend has continued through 2021 and 2022 and majority of our customers are choosing to manage their containerized applications through Kubernetes,” said Yrieix Garnier, VP of Product at Datadog. “These latest Kubernetes solutions enable Datadog to provide unparalleled performance and security to these customers as they continue to scale and grow their environments.”

    About Datadog
    Datadog is the monitoring and security platform for cloud applications. Our SaaS platform integrates and automates infrastructure monitoring, application performance monitoring and log management to provide unified, real-time observability of our customers’ entire technology stack. Datadog is used by organizations of all sizes and across a wide range of industries to enable digital transformation and cloud migration, drive collaboration among development, operations, security and business teams, accelerate time to market for applications, reduce time to problem resolution, secure applications and infrastructure, understand user behavior and track key business metrics.

    Forward-Looking Statements

    This press release may include certain “forward-looking statements” within the meaning of Section 27A of the Securities Act of 1933, as amended, or the Securities Act, and Section 21E of the Securities Exchange Act of 1934, as amended including statements on the benefits of new products and features. These forward-looking statements reflect our current views about our plans, intentions, expectations, strategies and prospects, which are based on the information currently available to us and on assumptions we have made. Actual results may differ materially from those described in the forward-looking statements and are subject to a variety of assumptions, uncertainties, risks and factors that are beyond our control, including those risks detailed under the caption “Risk Factors” and elsewhere in our Securities and Exchange Commission filings and reports, including the Annual Report on Form 10-K filed with the Securities and Exchange Commission on February 25, 2022, as well as future filings and reports by us. Except as required by law, we undertake no duty or obligation to update any forward-looking statements contained in this release as a result of new information, future events, changes in expectations or otherwise.page2image47096832

    Contact
    Dan Haggerty
    press@datadoghq.com

  • Defining the Next Cycle of Technology

    Defining the Next Cycle of Technology

    We’re in the middle of what we at ScyllaDB dubbed The Next Tech Cycle. Not “The World of Tomorrow” nor “The Shape of Things to Come” nor “The Wave of the Future”—because it’s already here today. We’re right in the middle of it. It’s a wave that’s carrying us forward, but it began with trends that got their start earlier this century.

    Everything is co-evolving, simultaneously, from the hardware you run on to the languages and operating systems you work with to the operating methodologies you use day-to-day. All of those familiar technologies and business models are themselves undergoing revolutionary change.

    This Next Tech Cycle Goes far Beyond “Big Data”

    We’re talking about huge data. Welcome to the Zettabyte Era. This era, depending on who is defining it and what it is measuring, either started in 2010 (if you’re measuring total data stored on earth) or in 2016 (if you’re measuring total internet protocol traffic in a year).

    Right now, individual data-intensive corporations are generating information at the rate of petabytes per day and storing exabytes in total. There are some prognosticators who believe we’ll see humanity, our computing systems and our IoT-enabled machinery generating half a zettabyte of data per day by 2025.

    Yet, conversely, we’re also seeing the importance of small data. Look at the genomics revolution.

    Because the RNA gene sequence of, say, COVID-19 is actually not that big, data-wise—you can store it in less than 100kb; less than an ancient floppy. But it is increasingly important to understand every single byte of that information because vaccinating against this global pandemic requires understanding every change of that rapidly-evolving pathogen.

    So, this next tech cycle has to scale everything from huge data and small data systems. And the database you will use and the data analytics you perform need to align with the volume, variety and velocity of the data you have under management.

    “Great! Now Make it All Multi-Cloud!”

    Also, this next tech cycle is not just the “cloud computing cycle.” AWS launched in 2006. Google Cloud was launched in 2008. And Microsoft Azure was formally launched in 2010. So, we’re already well over a decade past the dawn of the public cloud. Yet this next tech cycle definitely builds on the ecosystems, methodologies and technologies these hyperscalers provide.

    The database you use also has to align with where you need to deploy it. Does it only work in the cloud, or can it be deployed on-premises far behind your firewall? Does it just work with one cloud vendor or is it deployable to any of them? Or all of them simultaneously? These are important questions.

    Just as we do not want to be locked into old ways of thinking and doing, the industry does not want to be locked into any one technology provider.

    If you’ve just been mastering the art of running stateful distributed databases on a single cloud using Kubernetes, that’s not good enough. Now you’re being asked to do it all over again; this time in a hybrid or multi-cloud environment using Anthos, OpenShift, Tanzu, EKS Anywhere or Azure Arc.

    Computing Beyond Moore’s Law

    It’s also not the basic broadband or wireless internet revolutions. We’re a full two decades into both of those. Yet the advent of gigabit broadband and the new diverse range of 5G services—also capable of scaling to a gigabit—enable incredible new opportunities in real-time data streaming services, IoT and more.

    So how does your database work when you need to connect to systems far and near? How important are the limitations of the speed of light to your latencies? How well do you deal with data ingested from hundreds of millions of endpoints at gigabit-per-second scale?

    And finally, underpinning all of this are the raw capabilities of silicon, summed up by the transistor and core counts of current generation CPUs. We’ve already reached 64-core CPUs. The next generation(s) will double that, to the point where a single CPU will have more than 100 processors. Fill a rack-based high-performance computer with those and you can easily get into thousands of cores per server.

    And all of this is just traditional CPU-based computing. You also have GPU advancements that are powering the world of distributed ledger technologies like blockchain. Plus, all of this is happening concurrently as IBM plans to deliver a 1,000 qubit quantum computer in 2023 and Google plans to deliver a computer with one million qubits by 2029.

    This next tech cycle is powered by all of these fundamentally revolutionary capabilities. It’s what’s enabling real-time full streaming data from anyone to anywhere. And this is just the infrastructure.

    If you dive deeper into that infrastructure, you know that each of the hardware architecture bottleneck points is undergoing its own revolution.

    We’ve already seen CPU densities growing. Yet vanilla standalone CPUs themselves are also giving way to full systems on a chip (or SoCs).

    And while they’ve been used in high-performance computing in the past, expect to see commonly-available server systems with greater than 1,000 CPUs. These will be the workhorses —or, more specifically, the warhorses—of this next generation: Huge beasts capable of carrying mighty workloads.

    Memory, another classic bottleneck, is getting a huge boost from DDR5 today and DDR6 in just a few years. Densities are going up, so you can expect to see warhorse systems with a full terabyte of RAM. These and larger scales are going to be increasingly common—and, for businesses, increasingly affordable.

    Storage is also seeing its own revolution with the recently-approved NVMe base and transport specifications, which will enable much easier implementation of NVMe over fabrics.

    Now, software will have to play catch-up to these capabilities. Just as it took time for kernels and then applications inside of a vertically scaled box to be made async everywhere, shared-nothing, sharded-per-core, and NUMA-aware, this next tech cycle is going to require systems to adapt to whole new methodologies of getting the most from these new hardware capabilities. We will need to reconsider many foundational software assumptions.

    Evolving Methodologies: Agile and Beyond

    Speaking of methodologies, just look at these from the dawn of the millennium and onward. As an industry, we’ve moved from batch operations and monolithic upgrades performed with multi-hour windows of downtime on the weekend to a world of streaming data and continuous software delivery performed 24 × 7 × 365 with zero downtime ever.

    And by migrating to the cloud (and this always-on world) we’ve exposed ourselves and our organizations to a world of random chaos and security threats. We now have to operate fleets of servers autonomously and orchestrate them across on-premises, edge and multiple public cloud vendor environments.

    While Scrum has been around since the 1980s, and continuous integration since 1991, in this century, the twelve principles of the Agile Manifesto in 2001 altered the very philosophy—never mind the methodologies—underlying the way software is developed.

    The Agile Manifesto’s very first line talks about the highest priority being “to satisfy the customer through early and continuous delivery of valuable software.”

    However, the specific term continuous delivery (CD), as we know it today, didn’t take hold until 2009. It was then joined to continuous integration and coincided with the birth of what we now know as DevOps.

    With that, you had a framework for defining change-oriented processes and software life cycles through a responsive developer culture that now, a decade or two into this revolution, everyone takes as a given.

    This graph shows how continuous integration (CI) and continuous delivery (CD) evolved independently. They were eventually conjoined by the term CI/CD, whose popularity as a search term only began to rise around 2016 and did not displace the two separate terms until early in 2020. It is now increasingly rare to refer to CI or CD separately, according to Google Trends.

    Onto that baseline were built tools and systems and philosophies that extended those fundamental principles. The Chaos Monkeys of the world, as well as the pentesters, want to break your system—or break into them—to uncover flaws and defects long before something stochastic and catastrophic or someone maliciously does it for you.

    Cloud-native technologies like Kubernetes and single-source-of-truth for infrastructure methodologies like GitOps were created out of sheer necessity to scale systems to the hundreds of thousands of production software deployments under management.

    DevSecOps

    And that’s still not enough. We’ve already seen software supply chain attacks like SolarWinds, low-level system attacks like Spectre, Meltdown and Zombieload, or human-factor threats like viral deep fakes and millions of fictitious social media accounts using profile images generated by generative adversarial networks, never mind millions of IoT-enabled devices being nefariously harnessed for distributed denial-of-service (DDoS) botnet attacks. Just recently, news broke of the Log4j vulnerability—our best wishes to anyone who was patching code this past holiday season.

    These are all just the bowshocks of what’s still to come.

    So now, your AI-powered security systems are locked in combat every day in real-time against the threat actors attempting to undermine your normal operations. We know this because a growing number of intrusion prevention and malware analysis systems are built at terabyte-and-beyond scale using distributed databases as their underlying storage engines.

    Hence, these days, rather than just DevOps, increasingly we talk about DevSecOps—because security cannot be an afterthought. Not even for your MVP. Not in 2022.

    And these methodologies are continuing to evolve.

    Summary

    This next tech cycle is already upon us. We’re in the thick of it. You can feel it in the same way you’d yearn for major life or career change. Maybe it’s a programming language rebase. Is it time to rewrite some of your core code as Rust? Or maybe it’s in the way you are considering repatriating certain cloud workloads or extending your favorite cloud services on-premises such as through an AWS Outpost. Or maybe you’re actually looking to move data to the edge? Planning for a massive fan-out? Whatever this sea change means to you, you’ll need rock-solid infrastructure that’s available today to take workloads into production right now, but flexible enough to keep growing with your emerging, evolving requirements.

  • The Argo Project: Making GitOps Practical

    The Argo Project: Making GitOps Practical

    If you’re a DevOps engineer, chances are you have at least heard the name “Argo,” seen the friendly squid logo, and wondered: What the heck is this tool everyone is talking about? 

    In a nutshell, Argo is a popular open source tool that is making GitOps practical for anyone who uses Kubernetes. But it’s much more than that because, by enabling GitOps, Argo will also make Kubernetes environments more robust, secure and reliable than ever before. 

    Let’s find out why the combination of Argo, GitOps and good DevOps engineers is a recipe for production panacea.

    What is GitOps and Will it Replace DevOps?

    GitOps is a new(er) process and paradigm used by development teams to manage infrastructure and deploy applications. The “Git” in GitOps refers to the popular open source version control system. GitOps uses Git as a single source of information for declarative configuration. Based on this declarative configuration, it works its magic.

    GitOps automatically manages the configuration and deployment of infrastructure using Git pull requests. When development teams make a change to Git configuration, a GitOps agent deployed in the environment automatically reconciles the changes with the live state. Every change to the live environment is captured in the Git repository, so teams have unprecedented visibility and auditability over system changes. Most importantly, it is trivial to roll back to a previous working version in case of fires in production.

    GitOps builds on the developer experience, enabling teams to manage their infrastructure using the same tools and processes they use to develop software, extending those tools to the realm of software deployment and infrastructure management.

    While some have touted GitOps as “DevOps 2.0”, many experts disagree, saying that GitOps is not a better version of DevOps, nor is it something that will replace DevOps altogether. GitOps is a technical practice that can be highly beneficial to DevOps teams. The DevOps engineer will not, as some fear, be replaced by a Git-triggered robot. But GitOps will make her and the developers she supports happier and more productive.

    What is the Argo Project?

    Argo is an open source project hosted by the Cloud Native Computing Foundation (CNCF) for building and managing continuous delivery workflows in Kubernetes, GitOps style. The unique aspect of Argo is that it is Kubernetes-native—designed from the ground up for a modern containerized environment.

    The Argo project consists of four main sub-projects:

    • Argo CD—A GitOps continuous delivery engine with a powerful GUI and CLI.
    • Argo Workflows—A workflow engine that supports workflows and directed acyclic graphs (DAGs) in which each process stage is a container.
    • Argo Rollouts—An advanced Kubernetes deployment engine that supports progressive delivery strategies like canary and blue/green deployments, which are difficult to implement in plain Kubernetes.
    • Argo Events—A Kubernetes event-based dependency management system, which can be used to trigger automated workflows in CI/CD pipelines.

    Requirements for Kubernetes in Production

    Kubernetes is an orchestration platform that can help deploy, scale, and manage containerized applications. It can manage containers and the underlying infrastructure—scheduling containers and managing their workloads. This capability integrates software development and platform management to improve application management and portability. 

    Kubernetes in production can offer many advantages. For example, it makes it possible to release frequent changes to a high-availability application while keeping them online and enables you to move applications from one cluster to another. However, you need to configure Kubernetes correctly to realize its potential.

    Configuring Kubernetes for production involves implementing requirements according to each use case. As a result, what constitutes “production ready” in one Kubernetes project may vary greatly between different use cases. However, there are still minimum requirements that should be applied to most use cases. Here are key requirements for Kubernetes in production:

    • Security—When securing Kubernetes for production, you need to minimize the attack surface. This means locking down the Kubernetes control plane, applications, and their associated data. You need to keep secrets secured, harden nodes, use role-based access control (RBAC), and keep your Kubernetes version up-to-date with the latest security updates.
    • Portability and scalability—You can maximize cluster performance by maintaining portability and scalability. There are many Kubernetes capabilities that can help you achieve this goal, including self-healing nodes and auto scaling the infrastructure.
    • Deployment velocity—Kubernetes makes infrastructure and applications management faster by automating related processes. You can use Kubernetes’ automated features with GitOps to increase deployment velocity across your CI/CD pipelines.
    • Disaster recovery—You can significantly minimize your mean time to recovery (MTTR) by using Kubernetes and GitOps together. GitOps can help you reduce MTTR to minutes and quickly and easily recreate your container infrastructure in case of a complete cluster meltdown. 
    • Persistence—To support stateful production applications you will need to configure Kubernetes persistent volumes, provision storage devices with multiple storage tiers, and ensure they are efficiently utilized.
    • Observability—Observability enables you to gain a high-level view into running services, helping you make informed decisions before deployment to mitigate risk. GitOps can help you continuously monitor Kubernetes deployments, ensuring you can act immediately when issues occur.

    Benefits of Argo Tools for Production Environments

    Argo CD

    Argo CD is a continuous delivery (CD) tool native to Kubernetes. While most CD tools only support push-based deployment, Argo CD works in pull mode, retrieving updated code from a Git repository and deploying it directly to Kubernetes resources. This allows developers to manage infrastructure configuration and application updates in one system.

    Argo CD key features include:

    • Automatically synchronizing application state in a Kubernetes cluster with the current version of declarative configuration in a Git repository (==GitOps).
    • Ability to visualize deployment issues and detect and fix misconfigurations.
    • Convenient web-based GUI and CLI.
    • Role-Based Access Control (RBAC) and single sign-on (SSO), including login via GitHub, LinkedIn, Microsoft, etc.
    • Support for webhooks triggering actions in GitLab, GitHub, and BitBucket.

    How does Argo CD make Kubernetes production ready?

    GitOps can help you achieve a true GitOps workflows in Kubernetes, which provides the following benefits in production environments:

    • Minimize failed deployments and rapidly recover from downtime—Argo CD lets you instantly revert and rollback easily if anything goes wrong in production, reducing recovery time to seconds. 
    • Built-in auditing history—Argo CD ensures that every change to a Kubernetes cluster ia audited in the form of a Git configuration change log. This provides a complete audit trail of who changed what in the cluster, enabling consistent operations and supporting compliance requirements. 
    • Greater visibility on the lifecycle of developed features—Argo CD provides traceability from every change to infrastructure or applications directly to the code commit that caused those changes.
    • Improved security—Argo CD provides strong security guarantees, leveraging strong cryptography to manage changes and verify authorship, and creating a complete separation between CI environments and production systems, eliminating many types of supply chain attacks.

    Argo Rollouts

    Argo Rollouts is a set of Kubernetes controllers and CRDs that provides advanced deployment features such as blue/green and canary deployments, experiments, and progressive delivery in Kubernetes environments. It can integrate with input controllers and service meshes to incrementally transition traffic to new versions during updates. 

    A key capability of Argo Rollouts is that it can query and interpret metrics from many sources to validate that a deployment works properly and perform automatic upgrades or rollbacks.

    How do Argo Rollouts make Kubernetes production ready?

    By default, Kubernetes provides the Deployment object which updates applications using the “rolling update” strategy. In large production environments, rolling updates are considered too risky because there is no control over rollout speed and no way to automatically roll back in case of failure.

    Another limitation is that out of the box, Kubernetes deployments cannot query external metrics, such as real user measurements of performance or engagement, to determine the success of a deployment. 

    Argo Rollouts can address all these challenges and enable full progressive delivery in a Kubernetes environment, without requiring complex configuration.

    Argo Workflows

    Argo Workflows is an open source container-native workflow engine for orchestrating parallel tasks on Kubernetes. Argo workflows are implemented as Kubernetes Custom Resource Definitions (CRDs).

    Key features of Argo Workflows include:

    • Defining workflows where each step in the workflow is a container.
    • Modeling multi-step workflows as sets of actions or DAGs to capture dependencies.
    • Running CI/CD pipelines natively on Kubernetes without configuring complex software development products.

    How do Argo Workflows make Kubernetes production ready?

    Argo Workflows lets you automate production workflows in any Kubernetes environment, whether on-premises, hybrid cloud, or multi-cloud. It eliminates manual processes and ensures automation is represented as declarative configuration, making it consistent, repeatable, easy to rollback, and easy to troubleshoot.

    Argo Events

    Argo Events is a Kubernetes event-based dependency manager that defines multiple dependencies for different event sources (e.g. webhook, S3, schedule, stream, etc.) and Kubernetes objects after event dependencies are successfully resolved. Help the trigger.

    Argo events by themselves are not very useful. To deliver value, you need to integrate with a system that can execute workflow steps. So you can use Argo workflows to set Argo events. This helps orchestrate parallel Kubernetes jobs.

    How do Argo Events make Kubernetes production-ready?

    Argo Events provides several capabilities that enable dependency management in production Kubernetes environment:

    • Manage dependencies for various event sources.
    • Ability to customize business-level constraint logic to resolve event dependencies.
    • Manage everything from simple linear real-time dependencies to complex multi-source batch job dependencies.
    • Compliance with the CloudEvents standard.
    • Ability to manage event sources at runtime.

    Conclusion

    In this article, I covered the basics of GitOps and the Argo project and showed how each of the Argo project’s key modules can help make Kubernetes production-ready with minimal effort from developers and DevOps engineers. The magic of Argo is its simplicity and the way it fits seamlessly into existing Kubernetes workflows. I hope this will encourage you to try it out and see if it can help with your organization’s production issues.

  • Security Debt: Speed vs. Common Sense

    Security Debt: Speed vs. Common Sense

    A couple years ago, we had some spectacular security events that involved DevOps and Kubernetes, where the managing team simply redeployed containers whenever one crashed. It turned out that many organizations were doing the same thing, and, what’s worse, they were not talking about it because they knew it was not a long-term solution to crashing issues.

    At the time, I thought these high-profile lessons would teach people to actually fix code issues, even in high-throughput Agile-meets-DevOps shops. I admit I also laughed, yet again, at The Phoenix Project’s expense, thinking, “Yeah, but the CISO isn’t holding things up by demanding that get fixed!” I wish that would ever get old, but it won’t.

    It seems I was wrong. Or at least partially so. Some—perhaps many—shops seem to have missed the message that these issues sent. Anecdotally, we heard this was still happening, so we started asking questions. Yep. There are shops out there (since we started with ‘anecdotally,’ I won’t pretend to put numbers around it) that still take an “If it isn’t causing disruption in core systems, don’t fix it” mentality.

    Ouch. We’ll be revisiting some of those in the future, I’m sure—when it’s listed as a vulnerability or breach somewhere.

    I’m not a security professional. Because the vast majority of enterprises do not have dedicated security and even more don’t have anything close to enough security staff, I have done security as a part of almost every job I’ve taken—because it was what needed doing the most. Many, if not most of you, are in the same boat.

    That said, I can tell when you are blatantly asking for a security incident. And running code known to be faulty or misconfigured to the point that it repeatedly crashes is deliberately asking for a security incident. “But it isn’t exposed to the Internet!” is only a valid rebuttal until an attacker gets inside the perimeter and uses your fault for something like privilege escalation. Then no one cares if it’s connected to the internet or not; they want to know how the attacker did it. And that’s on you.

    So for those organizations in which speed has overridden common sense, let’s be very clear and to the point.

    It is a best practice not to run crash-level faulty software.

    Since you must not have one, write a policy that explains this and lays out a process and/or timeline to fix these problems. Then drive it home. Make certain it is known that this policy will be enforced. For that huge majority of my readers that don’t have the level of authority that “create and promulgate a policy” implies, convince those who do. Point out the issues to them in writing. “Notified in writing of faulty practices that could bite the company in the rear,” tends to get even the most unfriendly management to click into CYA mode and do something about it.

    When we all watched those spectacular failures back in the day, I assumed that this was all about growing pains; you can do so much more with Agile/DevOps/cloud and/or Kubernetes that this type of thing would crop up and, eventually, get addressed. I still believe that. You all are still testing the boundaries and pushing the limits and making all of IT look good. It’s just going to hurt getting there sometimes. Fix the apps, make the policy, keep kicking butt and know you are killing it (as an industry. If you aren’t, stop laughing at my blanket compliment and fix yourself).