Welcome!

@DevOpsSummit Authors: Liz McMillan, Pat Romanski, Elizabeth White, Yeshim Deniz, Zakia Bouachraoui

Related Topics: @DevOpsSummit, Java IoT, Linux Containers, @CloudExpo, @DXWorldExpo, SDN Journal

@DevOpsSummit: Blog Post

Why Scaling Down Is Harder Than Scaling Up

Elasticity should be non-disruptive

Elasticity is hailed as one of the biggest benefits of cloud and software-defined architectures. It's more efficient than traditional scalability models that only went one direction: up. It's based on the premise that wasting money and resources all the time just to ensure capacity on a seasonal or periodic basis is not only unappealing, but unnecessary in the age of software-defined everything.

The problem is that scaling down is much, much harder than scaling up. Oh, not from the perspective of automation and orchestration. That is, as the kids say these days, easy peasy lemon squeezy. APIs have made the ability to add and remove resources simplicity itself. There isn't a load balancing service available today without this capability - at least not one that's worth having.

But if you peek behind the kimono, you're going to quickly find out that perhaps it isn't as easy peasy as it first appears. Scaling down requires a bit more finesse than scaling up, at least if you care about the end user experience.

Consider for a moment the process of scaling up (or out, as is more often the case). A certain threshold is reached that indicates a need for more capacity. More often than not this metric is based on connections, with each application instance able to handle an approximate number of connections. When that is reached, a new application instance (node) is launched, it's added to the load balanced pool, and voila! More capacity, more connections, more consumers.

awkward elasticity

At some point that same threshold is breached on the way back down. As capacity demand wanes, the total connection count (as measured by all connections across all instances) decreases. When that count crossed a pre-determined threshold, one instance is shut down, it's removed from the pool, and voila!

You've just disconnected a whole bunch of consumers - many of whom might have been in the middle of a transaction (you know, trying to give you money).

Needless to say, they aren't happy.

That's because many of the systems implementing elastic scale these days haven't been load balancing applications for nearly twenty years and didn't recognize the importance of graceful degradation, or quiescence.

Graceful degradation was used in the olden days (and still is today, to be fair) when initiating a maintenance cycle. The requirement was that a server (today an instance) needed to be shut down for maintenance but it could not disrupt current user sessions. The load balancer would be "told" to begin quiescing (or bleeding off) connections in preparation for downtime. The service would immediately stop sending new connections to that server (instance) while allowing existing connections to complete. In this way, consumers could complete their tasks and when no connections were left, the server would be shut down and maintenance could begin.

This is not a simple thing to achieve. The load balancing service must be intelligent enough to stop sending new connections to an instance but not interrupt existing connections. It must be able to manage both active and semi-active instances for the same application, which requires stateful management across all application instances.

In today's models, this means that elasticity must embrace a more graceful, elegant means of scaling down than just suddenly killing an instance and all its associated connections.

With more and more apps - both those aimed at employees and those designed for consumers - residing in cloud environments and managed service environments, it is critical to evaluate how such providers support elasticity. Methods that disrupt productivity or interrupt consumer transactions are hardly worth the few pennies saved by immediately shutting down an instance when a threshold is crossed.

It behooves emerging software-defined models and devops that plan on managing scale automatically to recognize that elasticity isn't just about responding to thresholds; it's about responding seamlessly - in both directions.

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

@DevOpsSummit Stories
With more than 30 Kubernetes solutions in the marketplace, it's tempting to think Kubernetes and the vendor ecosystem has solved the problem of operationalizing containers at scale or of automatically managing the elasticity of the underlying infrastructure that these solutions need to be truly scalable. Far from it. There are at least six major pain points that companies experience when they try to deploy and run Kubernetes in their complex environments. In this presentation, the speaker will detail these pain points and explain how cloud can address them.
Discussions of cloud computing have evolved in recent years from a focus on specific types of cloud, to a world of hybrid cloud, and to a world dominated by the APIs that make today's multi-cloud environments and hybrid clouds possible. In this Power Panel at 17th Cloud Expo, moderated by Conference Chair Roger Strukhoff, panelists addressed the importance of customers being able to use the specific technologies they need, through environments and ecosystems that expose their APIs to make true change and transformation possible.
In an era of historic innovation fueled by unprecedented access to data and technology, the low cost and risk of entering new markets has leveled the playing field for business. Today, any ambitious innovator can easily introduce a new application or product that can reinvent business models and transform the client experience. In their Day 2 Keynote at 19th Cloud Expo, Mercer Rowe, IBM Vice President of Strategic Alliances, and Raejeanne Skillern, Intel Vice President of Data Center Group and GM, discussed how clients in this new era of innovation can apply data, technology, plus human ingenuity to springboard to advance new business value and opportunities.
DXWorldEXPO LLC announced today that "IoT Now" was named media sponsor of CloudEXPO | DXWorldEXPO 2018 New York, which will take place on November 11-13, 2018 in New York City, NY. IoT Now explores the evolving opportunities and challenges facing CSPs, and it passes on some lessons learned from those who have taken the first steps in next-gen IoT services.
The current age of digital transformation means that IT organizations must adapt their toolset to cover all digital experiences, beyond just the end users’. Today’s businesses can no longer focus solely on the digital interactions they manage with employees or customers; they must now contend with non-traditional factors. Whether it's the power of brand to make or break a company, the need to monitor across all locations 24/7, or the ability to proactively resolve issues, companies must adapt to the new world.