Container Tidbits: Does The Pets vs. Cattle Analogy Still Apply?

Background

So, most of us have heard the pets vs. cattle analogy. The saying goes, that in a cloud environment, you don’t waste time fixing individual virtual machines or containers – instead – you just delete them and re-provision. But, does this apply to the entire cloud environment? The analogy is that you don’t take cattle to the vet, you just send them to slaughter. But, is this really true? Cattle are worth a lot of money. I have never really liked the pets vs. cattle analogy.  I think it lacks sensitivity and may not be appropriate when talking to a CIO.  The real problem, however, is that the analogy fails to fully relate the changes in IT that are happening.

I propose that Pets vs. cattle is not really about how or when we kill animals – instead it’s about the simplicity of consuming animals, and the complexity of maintaining the environment in which they live.

Pets

At the end of the day – in small quantities, pets are actually quite easy to take care of – when they are young, you take them to the vet for their shots. As they grow, you provide them with food, water, and a clean litter box (or take them outside once in awhile) and they are pretty much “good to go”.

Like pets, you give traditional virtual machines their “shots” when they are first created (via Puppet, Chef, Ansible, or through manual updates) and they are pretty much “good to go”.  Of course, if they get “sick”, you take virtual machines to “the vet” – you log into them, troubleshoot problems, fix problems, or run update scripts. Usually by hand, or driven by some automation, but managed individually.

The problem is, raising pets in a house doesn’t scale. I don’t want 2000 cats and dogs at my house (and, let’s be honest, neither do you).

Cattle

Raising cattle is quite different than a household pet. It’s actually quite a bit more complex. Cows, sheep, and chickens are raised on farms because it’s more efficient. Farms are set up to handle the scale. This requires large amounts of land, tractors, fences, silos for grain/feed, specialized trailers for your truck, specialized train cars, and specialized processing plants. In addition, farms have to keep shifting which fields are used for grazing so that they don’t become unusable over time.  If you really think about it – I’m only just skimming the surface. Farms are more efficient, but quite a bit more expensive than a house to run day to day.

Clouds (e.g. OpenStack, OpenShift) are more akin to farms than houses. Firing up a cloud is like setting up a farm from scratch. It requires a lot of planning and execution. After firing up your cloud, there is constant technical care and maintenance – e.g. adding/removing storage – fixing hung instances – adding/removing VLANS – fixing pods stuck in a pending state, returning highly available services (Cinder, API nodes, OSE/Kube Master, Hawkular Metrics) back to production, upgrading the cloud platform, etc. etc. There is a lot of farm work with a cloud.

Farms are quite efficient at raising thousands of animals. I do not think, however, that you just tear down an entire farm when it is no longer running in an optimal state – instead – you fix it.  Clouds are quite similar. Clouds are more work for operators, but less work for developers. Just like farms are a lot of work for farms, but much less work for shoppers at the store.  Raising large amounts of chicken is harder for farmers and easier for consumers. The farmers hide the complexity from consumers.

Conclusion

I propose that it’s not really about pets vs. cattle, but really about houses vs. farms. It’s far easier to buy chicken breast at the store than it is to raise hundreds of chickens in your backyard. I propose this as an improved analogy. Farms require quite a bit of work, are sophisticated and more expensive than a house, but quite efficient at supporting a lot more animals. At scale, I would take a farm any day over raising thousands of animals at my house. The same is true with a cloud environment. At scale, a cloud wins every time.

On a side note, people often conflate the notion of scale up and scale out with pets vs. cattle. In my mind, bigger and smaller bulls (scale up/down) or a greater number of smaller bulls (scale out) is arbitrary and a constant challenge in terms of both pets and cattle….

Finally, for those that still don’t like pets vs. cattle or houses vs. farms – let’s try a beer analogy. Bottles vs. home brew – while it’s easy to drop by the store and buy a bottle of beer… it’s way more fun to brew it. Let’s brew some beer together, leave a comment below!

Schrodinger’s Container: How Red Hat is Building a Better Linux Container Scanner

The rapid rise of Linux containers as an enterprise-ready technology in 2015, thanks in no small part to the technology provided by the Docker project, should come as no surprise: Linux containers offer a broad array of benefits to the enterprise, from greater application portability and scalability to the ability to fully leverage the benefits of composite applications.

But these benefits aside, Linux containers can, if IT security procedures are not followed, also cause serious harm to mission-critical operations. As Red Hat’s Lars Herrmann has pointed out, containers aren’t exactly transparent when it comes to seeing and understanding all of their internal code. This means that tools and technologies to actually see inside a container are critical to enterprises that want to deploy Linux containers in mission-critical scenarios.

Continue reading “Schrodinger’s Container: How Red Hat is Building a Better Linux Container Scanner”

Architecting Containers Part 3: How the User Space Affects Your Application

In Architecting Containers Part 1 we explored the difference between the user space and kernel space.  In Architecting Containers Part 2 we explored why the user space matters to developers, administrators, and architects. In today’s post we will highlight a handful of important ways the choice of the user space can affect application deployment and maintenance.

While there are many ways for a given container architecture to affect and/or influence your application, the user space provides tooling that is often overlooked, namely

Continue reading “Architecting Containers Part 3: How the User Space Affects Your Application”

Architecting Containers Part 2: Why the User Space Matters

In Architecting Containers Part 1 we explored the difference between user space and kernel space. In this post, we will continue by exploring why the user space matters to developers, administrators, and architects. From a functional perspective, we will explore the connection that both ISV applications and in-house application development have to the user space.

Continue reading “Architecting Containers Part 2: Why the User Space Matters”

What is Deep Container Inspection (DCI) and Why is it Important?

The format of container images is at the center of industry attention because it is so important to the adoption of containers.  With the advent of the Open Container Initiative (OCI), it seems appropriate to compare container images to network protocols.  Before TCP/IP became the defacto standard network protocol stack, each vendor was left to devise their own.  Some leveraged IPX/SPX, while others standardized on AppleTalk.  This made it difficult to create robust tooling.  Much like network protocols, standardizing the bit level format of a container image, allows the industry to focus on higher level business problems, and more importantly, their respective solutions.

Continue reading “What is Deep Container Inspection (DCI) and Why is it Important?”

Architecting Containers Part 1: Why Understanding User Space vs. Kernel Space Matters

Perhaps you’ve been charged with developing a container-based application infrastructure?  If so, you most likely understand the value that containers can provide to your developers, architects, and operations team. In fact, you’ve likely been reading up on containers and are excited about exploring the technology in more detail. However, before diving head-first into a discussion about the architecture and deployment of containers in a production environment, there are three important things that developers, architects, and systems administrators, need to know

Continue reading “Architecting Containers Part 1: Why Understanding User Space vs. Kernel Space Matters”

What’s Next for Containers? User Namespaces

What are user namespaces? Sticking with the apartment complex analogy, the numbering of users and groups have historically been the same in every container and in the underlying host, just like public channel 10 is generally the same in every unit in an apartment building.

But, imagine that people in different apartments are getting their television signal from different cable and satellite companies. Channel 10 is now different for for each person. It might be sports for one person, and news for another.

Historically, in the Linux kernel, there was a single data structure which held users and groups. Starting in kernel version 3.8

Continue reading “What’s Next for Containers? User Namespaces”

  • Page 2 of 2
  • <
  • 1
  • 2