devopsy.kinsta.cloud

Tag: cattle vs pets

  • Cattle, Not Kittens – Revisited

    Cattle, Not Kittens – Revisited

    The early days of DevOps were filled with pronouncements that we needed to treat our servers as cattle, not pets (kittens). For a year or so, the refrain was everywhere. And we did. We detached servers from dedicated hardware, we made spin up and spin down so easy that we just replaced malfunctioning servers (which has caused its own problems), we have even made servers designed to spin up, do one thing well, then spin back down until needed again – something unthinkable even a decade ago.

    And we’ve reaped benefits. Servers suck up less attention from the DevOPS side, and standardization has made it easier to code for them, moving things along and allowing members of another team to pitch in when there is a crunch because of familiarity.

    But IT is filled with people, and something happened in the transition. In hindsight, we should have seen it as a possibility, but things changed so much, so fast that I don’t think anyone was considering this possibility.

    Our DevOps tools/toolchains/processes became our pets (kittens).

    Now the special snowflake that requires specific knowledge and has to be treated with kid gloves is the DevOps step, not the servers it uses. Like pet servers, a fragile step that is working is avoided like the plague, when it should be shored up. Like pet servers, a process that is locked into a specific tool, OS, or platform is left that way, even when other options are a better solution. Like pet servers, the person who “knows all about” that is left to manage the step that should, by all rights, be easily understandable by anyone on the DevOps team.

    It’s time to start treating DevOps like cattle, not kittens. Some steps (like some servers) will be more difficult to make less pet-like and more cattle-like, but if history is any gauge, the payoff is worth the investment.

    We don’t have a cross-toolset language, other than doing things in the various shells and calling the shell scripts from a given toolset (not the best solution, just an example of where we’re at), but that shouldn’t stop us from standardizing and genericizing as much as possible. Less fragility, more reusability and a broader support team is good for everyone.

    You all are knocking it out of the park. We – all of us – are spending more time at work and at home in the digital space than ever before, and, generally speaking, the tools “just work.” That’s all on you. Keep kicking it. But standardizing to keep things running smoothly just makes sense. You know your org; it is possible that the easiest route to cattle is to standardize on a single toolchain (perhaps one or two toolchains with reusability documented) possibly to shove a bunch of steps into scripts and share amongst whatever tools each team chooses (I, and history, strongly discourage this approach, but neither I, nor history, has to live in your environment. There might be a good reason for this, so I include it here).

    All I’m saying is, don’t re-implement every step over and over if you can avoid it, and don’t make steps so arcane that you need a specialist (not internal, and definitely not external). Keep rocking it, and get those cattle moving!

  • Launching Applications to the Cloud – It’s all about Scalability and Speed

    Launching Applications to the Cloud – It’s all about Scalability and Speed

    It is not hyperbolic to state that today’s web services deal in hyperscale realms when one considers stats such as

    • The Amazon cloud can handle up to 1 million transactions per second during peak loads
    • Facebook was managing 890 million daily active users on average for December 2014
    • There are 500 million tweets sent per day and 80 percent of those are sent from mobile devices

    Ironically, the move to hyperscale web services has been made possible by applications going micro, as in microservices as commonly defined as “small, independent processes communicating with each other using language-agnostic APIs.” The emergence of microservices based application architectures is a revolutionary departure from monolithic app development, which was purpose-built around a single service, e.g. storage management, CRM, etc. In its place now are 10 or more modular, reusable services each owning a limited and specific set of functionality in what might be best illustrated as replacing a singular black box with a set of Lego blocks.

    In turn, this has led directly to key advancements in the application development process, evolving from start-to-finish programming to agile, continuous integration/continuous development (CICD). This model offers two major advantages over the waterfall development approach:

    • One, decreasing software development time to align to the “speed of business” dictated by market factors and not by IT processes.
    • Two, enabling specific modules of an application to achieve “autonomous elastic scale” where instances can be scaled up or down dynamically and on an as-needed basis.

    The software world and its professionals are intimately familiar with these application megatrends, of course. They live it every day. However, they may be less familiar with what’s happening — or to be more precise what’s not happening — with the evolution of networking, specifically in the layer that manages server load balancing or application delivery control (ADC).

    This is so because legacy ADCs were built and optimized for applications that resided in a single hardware platform and at a single location. With the advent of Microservices, the days of a cozy 1-to-1 relationship between the ADC and a monolithic application is quickly becoming a thing of the past. A useful analogy here is to equate the management of these resources with how humans treat cattle vs. pets.

    Application microservices are like cattle in that while these resources are valuable, each resource can be easily replaced. Legacy ADCs are like pets in that they’re not easily replaceable and, at times, require painstaking levels of care and attention.  Indeed, it is clear that the pace of innovation for these networking devices has not kept pace with the requirements of application microservices in their current forms as either hardware appliances or as self-contained VM appliances.

    Though legacy ADCs may be upgraded to be microservice “aware” and even provide certain levels of integration; they are not optimized to support an application architecture that’s built on microservices written in different programming languages and distributed across many different hardware platforms, clouds, and even data center locations.

    The solution requires ADCs and load balancers to evolve to take on more of the characteristics microservices possess (be more like cattle and less like pets), namely:

    • Being tightly aligned with each app microservice and not with the entire monolithic app;
    • Delivering a consistent set of network services in a location-agnostic way, whether the app location is on-premises in a data center or distributed across private and public clouds;
    • Being hardware agnostic, whether the app is on bare metal, in VMs, or even in containers – without requiring additional configuration tools; and
    • Achieving autonomous and elastic scale to support each microservice throughout its useful lifecycle.

    Further, this evolution must be true and profound and not a mere incremental advancement, which has hindered the adoption of software-defined data centers among the large enterprise segments thus far.

    Specifically, ADCs must achieve the concept of “application affinity” which is based on the app-world concept of “processor affinity” where resources are aligned/pinned for specific functions. There are two major benefits to this approach. First, having the ADC resource side-by-side, the microservice will improve the application response time. The application delivery follows the “destiny” of the microservice – it grows, shrinks and moves with the app itself.

    Second, this tight alignment (affinity) enables ADC resources to achieve automatic lifecycle management of microservices without manual intervention, which reduces management complexity significantly.

    In summary, it’s been said that best things tend to come in small packages. Such is the case with the emergence of application microservices, which has paved the way for agile, continuous application development and hyperscale web services.

    It’s time for the ADC to undergo a similar evolutionary path in order to maintain its strategic value as the gateway between the network and application layers.

    About the Author/ Dhritiman Dasgupta

    DD_Exec MugDhritiman Dasgupta  the VP of Marketing Avi Networks.Prior to joining the Avi Networks team, Dhritiman Dasgupta (aka DD) was a Vice President at Juniper Networks where he headed up the data center, security, and SDN marketing efforts.  He launched the award-winning QFabric and MetaFabric systems. Prior to Juniper, DD spent 9 years at Cisco Systems in the LAN and Data Center switching divisions heading up product management for several multi-billion dollar platforms including the Catalyst series switches.  https://twitter.com/mandhriti